Event-Driven Architecture
Services communicate by producing and consuming events asynchronously through a central event bus or message broker.
★★★★★4/5System topology — how multiple services are organised
Interactive visualization
LiveHow it works
In Event-Driven Architecture (EDA), components communicate by emitting events. A producer publishes an event to a broker (Kafka, RabbitMQ, AWS SNS/SQS) without knowing which consumers will process it. Consumers subscribe to relevant events and react independently.
Two main topologies: mediator (a central orchestrator routes events) and broker (components react directly to events on a shared bus). EDA enables extremely loose coupling and natural support for audit logs via event replay.
The main challenge is reasoning about eventual consistency — after a producer emits an event, downstream effects may take milliseconds or seconds.
Why it matters
EDA is the backbone of real-time systems. It enables loose coupling at scale and naturally supports streaming analytics, audit trails, and cross-domain integration.
✓ When to use
- →Real-time data pipelines and streaming analytics
- →Integrating multiple systems that should stay decoupled
- →Audit logging and event replay requirements
- →Workflows where multiple services react to the same event
✗ When NOT to use
- →Simple request/response CRUD with no async requirement
- →When strong consistency is required (EDA is eventually consistent)
- →Small systems where a message broker adds unnecessary complexity
Trade-offs
Extreme loose coupling — producers don't know consumers
Eventual consistency is hard to reason about and debug
Natural scalability — consumers can scale independently
Event schema evolution (versioning) requires careful management
Built-in audit log via event history
Harder to trace request flows without distributed tracing tools
In production
Kafka processes > 7 trillion events/day for activity feeds and analytics
Real-time dispatch and surge pricing driven by location events
Pricing, availability, and notifications all driven by booking events
Industry adoption
Related principles
Event Sourcing
LiveStore state as an immutable log of events rather than the current snapshot — rebuild state by replaying events.
CQRS
LiveSeparate the model used to read data (Query) from the model used to write data (Command) — each optimised independently.
Microservices Architecture
LiveDecompose an application into small, independently deployable services that communicate over a network.
Saga Pattern
LiveManage distributed transactions across services using a sequence of local transactions with compensating rollbacks on failure.