Definition
Event-driven architecture (EDA) is a system design style in which components communicate by producing and consuming events — discrete, immutable records of something that happened — rather than by direct, synchronous calls. A producer publishes an event to a broker or bus; one or more consumers subscribe and react. The producer does not know which consumers exist or what they will do, and the consumer does not know which producer emitted the event. The coupling between components is mediated entirely by the shape of the event and the contract of the broker.
EDA is an architectural style, not a specific technology. It can be realized with message brokers (Kafka, RabbitMQ, NATS, Pulsar), with cloud event services (SNS/SQS, EventBridge, Pub/Sub), or with simpler in-process event buses. What distinguishes it from request-response architectures is the asynchronous, broadcast-shaped flow: events fan out to whoever cares, in whatever order they are consumed, with no synchronous return value back to the producer.
Why it matters
How it works
A producer emits an event to a topic or stream on a broker. The event carries a name (OrderPlaced, TradeExecuted, UserSignedUp), a timestamp, a payload describing the fact, and metadata used for routing or correlation. The broker persists the event and exposes it to consumers. Consumers subscribe to topics, process events as they arrive, and update their own state, emit downstream events, or both. Different consumers can process the same event for different purposes — one updates a search index, one writes to a warehouse, one sends a notification — without any of them knowing about each other.
Three operational realities shape every EDA in practice. First, schema evolution: events outlive the code that produces them, so adding fields must be backward-compatible and removing fields requires careful versioning. Second, ordering and idempotency: most brokers guarantee order only within a partition, and any consumer may see the same event more than once after a failure, so handlers must be safe to retry. Third, observability: with synchronous calls a stack trace tells you what happened; with EDA you need correlation IDs, consumer-lag dashboards, dead-letter queues, and explicit replay tools. Variants like event sourcing (the event log is the system of record) and CQRS (separate read and write models) take the pattern further by making events not just an integration mechanism but the primary representation of state.