What is event-driven architecture?
In an event-driven system, components announce that something happened — an order was placed, a user signed up — and other components react, without the sender knowing who listens. A message broker carries these events. It decouples services so they can evolve independently.
Why it matters
As a system grows into multiple services, tight request-response coupling makes every change risky. Events let services react to each other without direct calls, improving resilience and scalability. But they introduce eventual consistency, which you must design for honestly rather than pretend away.
What to learn
- Events vs commands
- Publish/subscribe and topics
- Message brokers: Kafka, RabbitMQ, and managed options
- Eventual consistency and what it means for reads
- Event ordering and delivery guarantees
- The outbox pattern for reliable publishing
- When events add more complexity than value
Common pitfall
Assuming events arrive instantly and in order, then showing users data that has not caught up yet. Event-driven systems are eventually consistent — there is a window where a read does not reflect a recent write. Design the UI and the data flow to tolerate that window instead of treating it as a bug.
Resources
Primary (free):
- Microsoft — Event-driven architecture · docs
- Confluent — What is pub/sub? · docs
- microservices.io — Saga pattern · docs
Practice
Take two responsibilities that are currently coupled — say creating an order and
sending a confirmation — and decouple them with an event. Publish an
order.created event and have a separate handler react to it. Describe the
window of eventual consistency this introduces. Done when the two no longer call
each other directly.
Outcomes
- Distinguish events from commands and pub/sub from direct calls.
- Explain eventual consistency and design reads around it.
- Publish events reliably with the outbox pattern.
- Judge when event-driven design is worth its complexity.