CQRS (Command Query Responsibility Segregation) — Part 2: Internals & Event Sourcing

maang.io System Design Series

What is this?

Back to the restaurant. In Part 1 we stood at the door and saw the two machines — the kitchen (commands) and the order board (queries) — with a channel running between them. Now we walk into the back and watch the actual machinery: how a ticket becomes cooked food and then becomes a line on the board, what the "channel" really is, where the kitchen keeps its authoritative record, and every place a real kitchen catches fire on a Friday night.

The single most important upgrade in this chapter is what the kitchen writes down. A naive kitchen stores only the current state ("Table 12: salmon, ready"). A great kitchen keeps the ticket spike — the metal spike where every ticket is impaled in order, never erased: "order placed," "salmon fired," "order ready," "order paid." That append-only spike is Event Sourcing, and once the kitchen has it, every board on the wall becomes a disposable replay of the spike. This is the pairing that makes CQRS truly powerful, so we'll build up to it deliberately.

The one-line idea: The write side turns a command into one or more events (facts about what happened) and durably records them; a projector consumes those events and folds them into each read model. Get the recording atomic, the projectors idempotent, and the ordering per-aggregate, and CQRS is rock-solid. Miss any of the three and you get lost writes, double counts, or corrupt views.