Integration
Event-Driven Integration Architecture
In an event-driven integration architecture, systems communicate by publishing and reacting to events, which record something that has happened, such as an order being placed or an invoice being paid. Producers don't need to know who consumes their events, keeping systems loosely coupled and enabling data to flow as soon as changes occur.
Core concepts
- Event: an immutable fact with a type, payload and timestamp.
- Producer: the system that publishes the event.
- Broker or event channel: the infrastructure that stores and distributes events.
- Consumer: any system that subscribes and reacts.
- Event schema: the contract describing the event's structure, ideally versioned.
How it works
Producer
Event published
Broker / channel
Consumers react
When a customer changes their address, the CRM publishes a single event. Billing, logistics and analytics each consume it independently. Adding a new consumer requires no change to the CRM.
Events can originate from applications or directly from databases using Change Data Capture (CDC), which turns committed data changes into event streams without modifying the source application.
Event-driven vs. request/response
| Request/response | Event-driven | |
|---|---|---|
| Coupling | Caller must know and wait for the callee | Producer unaware of consumers |
| Timing | Synchronous | Asynchronous, near real time |
| Failure impact | Callee outage blocks caller | Events buffered until consumers recover |
| Typical use | Queries, commands needing an immediate answer | Propagating state changes, notifications, streams |
Design considerations
- Delivery guarantees: at-most-once, at-least-once or effectively-once; consumers should be idempotent.
- Ordering: guarantee order where it matters, typically per entity key.
- Schema evolution: add fields compatibly and version breaking changes.
- Replay: retaining events allows new consumers to rebuild state.
- Observability: monitor lag, throughput and dead-letter queues.