Lesson 13 / 32
Event-Driven Architecture & CQRS
Reacting to things that happened, and splitting reads from writes.
Events instead of calls
In event-driven architecture, a service publishes a fact ('OrderPlaced') instead of calling other services directly. Interested services subscribe and react independently — the publisher doesn't know or care who's listening.
Loose coupling, new failure modes
Publishers and subscribers can be deployed, scaled, and fail independently — great for growth. The cost: no single trace of a request end-to-end, and you need event schemas and versioning discipline as more services join.
Bulletin board vs phone call
A direct call is a phone call — you need the other side to pick up now. Publishing an event is pinning a notice on a bulletin board: anyone can read it whenever they pass by, and you can add more readers later without asking the board's permission.
Quick check: CQRS separates a system's model into which two paths?
- Cache vs database
- Reads (queries) vs writes (commands)
- Sync vs async
Answer
Reads (queries) vs writes (commands) — CQRS (Command Query Responsibility Segregation) uses a write model optimized for commands and a separate, often denormalized, read model optimized for queries.