Event-Driven Architecture: When It's the Right Choice and When It's Not

Event-driven architecture is having a moment. Message queues and event streams appear in architecture diagrams with increasing frequency, often applied to problems that would be better solved with a direct API call. Understanding when EDA is the right choice — and when it’s adding complexity without commensurate benefit — requires clarity about what problems it actually solves.

What EDA Solves Well

Temporal decoupling: producer doesn’t need consumer to be available to complete its work. Workload smoothing: absorb bursts of events and process them at a sustainable rate. Audit trails: every event is a record of something that happened. Fan-out: one event processed by multiple independent consumers without the producer knowing about any of them. These are genuine capabilities that direct request/response architectures provide poorly or not at all.

What EDA Makes Harder

Debugging: the causal chain between an action and its effects becomes harder to trace when they’re separated by an event queue. Consistency: eventual consistency is a real tradeoff that requires careful design of every consumer. Operational complexity: message queues, schemas, and consumer offsets are additional infrastructure to operate and monitor.

The Decision Heuristic

If the producer cares whether the consumer succeeded, use a direct call. If the producer doesn’t care, and the work can be retried safely, and there are multiple consumers or significant load variation — that’s the EDA use case. Applying this heuristic eliminates most of the inappropriate EDA applications we see in practice.