Integration
Event-Driven Integration Architecture
When events are the right integration style, and the design work that makes them operable.
5 min read
Choosing the integration style
Request-response APIs suit synchronous, query-style interactions where the caller needs an immediate answer. Events suit notification of state change, fan-out to multiple consumers, and workloads that must tolerate temporary unavailability of downstream systems.
Most enterprises need both. The architectural decision is which interactions belong to which style, documented as a rule rather than settled per project.
What has to be designed explicitly
Event-driven designs move complexity from integration code to operational concerns.
- Event schemas, versioning and compatibility rules
- Ordering and partitioning strategy
- Idempotency and duplicate handling in consumers
- Replay, dead-letter handling and poison-message policy
- Observability: end-to-end tracing across asynchronous hops
Avoid the distributed monolith
Events do not decouple systems on their own. If consumers depend on the producer's internal structure, the coupling has simply moved into the message payload. Publish domain events that describe business facts, not database rows.
Working through this in your own environment?
We help organisations make these decisions with the constraints they actually have.