Event-Driven Architecture

Event-driven architecture (EDA) structures a system around the production, detection, and consumption of events — notifications that something significant has happened, such as "order placed" or "payment failed." Producers emit events without knowing who will handle them; consumers react independently. This inversion of control yields loose coupling and natural asynchrony.

How It Works

Events flow through a broker or log: a message queue (RabbitMQ, SQS), a streaming platform (Kafka, Pulsar, Kinesis), or an event bus (EventBridge). Two broad topologies exist:

• Broker/choreography: services subscribe to events and chain reactions with no central coordinator. Highly decoupled but harder to trace end-to-end.
• Mediator/orchestration: a coordinator routes events through a defined workflow, easier to reason about but a potential bottleneck.

Events may be thin notifications (carrying just an ID) or fat "event-carried state transfer" messages (carrying enough data that consumers need not call back). Delivery guarantees (at-least-once, exactly-once) and ordering shape consumer design; idempotent handling is essential because most brokers deliver at least once.

When to Use It

Use EDA when components must be decoupled and evolve independently, when workflows are inherently asynchronous, or when many consumers care about the same change. It underpins real-time analytics, IoT ingestion, microservice integration, and reactive UIs. It scales well: producers and consumers scale separately, and bursts are absorbed by the broker.

Trade-offs

Asynchronous, eventually consistent flows are harder to debug and test than synchronous calls; there is no single stack trace across services. Ordering, duplicates, and partial failures require careful handling. Choreography can become an implicit, hard-to-see workflow spread across many services. Operational maturity — schema management, dead-letter queues, observability, and replay — is a prerequisite, not an afterthought.

Related Patterns

EDA is the backbone for event-sourcing, command-query-responsibility-segregation propagation, and the saga-pattern for distributed transactions. It commonly uses choreography with idempotent consumers.

Example

When a customer places an order, the order service emits an OrderPlaced event to Kafka. The inventory service reserves stock, the payment service charges the card, the notification service emails a receipt, and an analytics consumer updates dashboards — all reacting independently. New consumers can be added later without touching the order service.