Event-Driven Architecture
Systems that communicate by emitting and reacting to events rather than calling each other directly — loose coupling and scale, bought with eventual consistency and debugging difficulty.
What is event-driven architecture?
In event-driven architecture (EDA), components communicate by producing and consuming events — “order placed,” “payment succeeded” — rather than calling each other’s APIs directly. A producer emits an event to a broker (message queue, event bus, or log like Kafka) and moves on, indifferent to who consumes it; any number of consumers react independently. The defining property is temporal and referential decoupling: the producer doesn’t know its consumers exist, and they needn’t be available when it fires.
What decoupling buys — and costs
The benefits are real. Independent scaling and evolution: add a new consumer (fraud check, analytics, notification) to an existing event stream without touching the producer — the extensibility that makes EDA attractive for growing systems. Resilience: a slow or failed consumer produces a backlog, not a cascading timeout through synchronous callers. Natural fit for async workloads. The costs are equally real and routinely underestimated. Eventual consistency: the order exists before the inventory reflects it — user-visible “I paid but it says pending” states must be designed for, not wished away. Debugging is genuinely hard: no single call stack spans an event flow, so tracing “why didn’t this happen?” across producers, brokers, and consumers demands correlation IDs and distributed tracing from day one. Delivery semantics force idempotency (at-least-once means duplicates) and dead-letter handling.
Choreography vs orchestration
Two coordination styles: choreography (each service reacts to events autonomously — maximally decoupled, but no one place shows the whole business process, so complex flows become emergent and hard to follow) versus orchestration (a central coordinator directs the sequence — clearer, more coupled). Mature systems mix them: choreography for loose reactions, orchestration (Step Functions, sagas) for multi-step transactions that need a visible flow and compensation logic.
What people get wrong
- EDA everywhere — synchronous request/response is simpler and correct for plenty of interactions; events aren’t a universal upgrade.
- Ignoring eventual consistency in the UX until users complain about “pending” states.
- No correlation IDs or tracing — then discovering event flows are nearly undebuggable in production.
Primary source: AWS — Event-Driven Architecture
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.