Event-driven architecture
Event-driven architecture is the design pattern where services communicate by emitting and consuming events rather than by direct synchronous calls. A service emits an event (an immutable fact about something that happened); other services subscribe and react. The pattern decouples producers from consumers and enables independent scaling and evolution.
EDA's central benefit is decoupling: the producer doesn't know who consumes the event or how, and consumers can be added or removed without changing the producer. The pattern fits naturally with microservices, CQRS, and event sourcing. The trade-offs are operational: debugging distributed event flows is harder than tracing synchronous calls; ordering and idempotency become explicit concerns; eventual consistency replaces strong consistency. Common implementations: Kafka, AWS EventBridge, Google Pub/Sub, NATS, RabbitMQ. The pragmatic guidance: EDA shines for workflows that are naturally asynchronous (notifications, indexing, analytics) and is overkill for simple CRUD.
Related terms
- Event sourcing
Event sourcing is a persistence pattern that stores every state change as an immutable event in an append-only log.
- CQRS
Command Query Responsibility Segregation is an architectural pattern that splits a system's write path (commands that change state) from its read path (queries that return state) — typically with separate models, sometimes separate databases.
- Saga pattern
A saga is a sequence of local transactions across multiple services that together accomplish a distributed business transaction.