The idea
CQRS stands for command query responsibility segregation. It splits the system into a write side that handles commands and a read side that serves queries, each with its own model and store.
Why split them
The shapes of reads and writes often conflict.
- Writes want a normalized model that enforces invariants.
- Reads want denormalized views shaped for fast queries.
By separating them, each side scales independently. You can add many read stores tuned for specific screens while keeping one authoritative write store.
How they stay in sync
The write side emits events when state changes. Projectors consume those events and update read models.
- Read models are eventually consistent with the write side.
- A slow read view does not block writes.
- You can rebuild a read model by replaying events.
CQRS adds moving parts, so use it where read and write demands truly diverge.
Key idea
Separate commands from queries so reads and writes scale and evolve independently.