Event-driven architecture (EDA) is a design style in which the parts of a system communicate by producing and consuming events rather than by calling one another directly. A producer announces that something has happened — an order was placed, an account was created — without knowing or caring who, if anyone, is listening. Consumers subscribe to the events they care about and react on their own terms. This indirection is the source of EDA’s defining benefit: loose coupling between the component that emits a change and the components that respond to it.
Martin Fowler, in “What do you mean by Event-Driven?”, cautions that the term is used loosely and bundles together several distinct patterns that are easily confused. The simplest is event notification, where a system “sends messages to notify others of domain changes.” Fowler notes a real cost to this style: because the reaction lives in a separate place from the trigger, “it can be hard to see such a flow as it’s not explicit in any program text.” The flow of control becomes emergent rather than written down in one place.
A second pattern is event-carried state transfer, in which the event carries enough data that consumers can maintain their own local copy of the information and avoid querying the source system. This improves resilience and reduces coupling further, at the price of duplicated state that must be kept consistent. Fowler treats two further patterns — event sourcing and Command Query Responsibility Segregation — as related but separate ideas that are frequently combined with event-driven communication, which is part of why the label causes confusion.
Architecturally, events typically flow through a broker or messaging layer that decouples producers from consumers in time as well as in identity. Message queues and publish-subscribe systems let producers fire and forget while consumers process at their own pace; event streaming platforms retain the events as a durable, replayable log. These substrates mean a producer and consumer need not be running at the same instant, and new consumers can be added later without touching the producer.
The appeal of EDA is scalability and evolvability: services can be developed, deployed, and scaled independently, and new behavior can be bolted on by subscribing to existing events. The trade-off, as Fowler stresses, is that the overall logic of the system becomes harder to follow, debugging spans many components, and reasoning about consistency and ordering takes real care. Used deliberately, it underpins much of modern distributed and microservice design; used reflexively, it scatters a program’s logic across a system no one can fully see.