Event-driven architecture

Event-driven architecture (EDA) is a software design pattern in which systems communicate by producing, detecting, and consuming events rather than by invoking each other through direct synchronous calls. In an EDA, a component emits an event when its state changes; other components react to that event by updating their own state, triggering additional events, or performing side effects. The architecture is built on message queues, event buses like Amazon EventBridge, and log-based streaming platforms like Apache Kafka, which serve as the communication infrastructure that decouples producers from consumers.

The central abstraction of EDA is the event — a record of something that has happened, not a command to do something. This distinction between events and commands is architecturally significant. A command is imperative ('do X'); an event is declarative ('X happened'). Commands create coupling: the sender must know the receiver's interface and must handle the receiver's failure. Events create a different coupling: the sender must know the event bus, and the receiver must know the event schema. The coupling is relocated, not eliminated, and the event schema becomes the system's implicit contract.

EDA enables loose coupling, horizontal scalability, and temporal decoupling, but it introduces failure modes that are harder to debug than synchronous failures: event loss, duplicate processing, out-of-order delivery, and cascading event storms. The architecture is not a universal improvement over request-response; it is a tradeoff that optimizes for flexibility at the cost of traceability.

The provocation: event-driven architecture is the distributed systems equivalent of a Rube Goldberg machine. Each component is simple, but the chain of events is opaque, and the failure of any link produces failures that are distant in both time and space from their cause. The architecture that claims to decouple is the architecture that makes coupling invisible.