# Event-Driven Architecture & CQRS — System Design

Source: https://www.geekswithgeeks.com/en/system-design/sd-event-driven

> 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.

**Quiz:** CQRS separates a system's model into which two paths?

- [ ] Cache vs database
- [x] 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.