Patterns / Integration Architecture
Event-Driven Architecture
Producers publish facts; consumers react independently. Decoupling in time, scale, and ownership.
Producers
Event Backbone
Schema Registry
Consumers
Data Products
Conceptual flow
Problem
Synchronous chains make every consumer a dependency of every producer, and one slow system stalls the business process.
Context
High-volume, asynchronous domains — telemetry, orders, meter reads, asset events — with many independent reactions per fact.
Solution
Model business facts as immutable events on a durable log with schema contracts, consumer groups, replay windows, dead-letter handling, and idempotent consumers.
Benefits
- Temporal decoupling
- Independent scaling
- Replay and audit
- New consumers without producer change
Risks
- Eventual consistency confusion
- Schema evolution mistakes
- Debugging across hops
Trade-offs
- Autonomy over immediate consistency
- Operational tooling investment
When to use
- Many reactions to one fact
- Bursty or high volume
- Long-running processes
When not to use
- Strict read-after-write requirements
- Simple CRUD with one consumer
Related patterns
Discuss this pattern
How have you applied it — and where did it break? Bring your experience to the community.
Open the discussion