CQRS: separating reads from writes
CQRS splits the model that changes data from the model that reads it. It can solve scale and complexity problems, and it can add many.
CQRS stands for Command Query Responsibility Segregation. The idea: use one model to change data (commands) and a different model to read it (queries).
The problem it solves
One model for both often becomes a compromise. Writes want a clean, normalised structure with strict rules. Reads want data shaped for screens: joined, filtered, summarised and fast. As an app grows, forcing both onto the same tables creates slow queries and tangled code.
How it works
- Command side: handles actions like
PlaceOrder. It validates business rules and writes to the write store. - Query side: serves reads from a read model shaped exactly for the screens or APIs (for example a denormalised "order summary" table, a search index or a cache).
- Synchronisation: after a write, the change is sent (often as an event through a queue) to update the read model.
The cost: eventual consistency
The read model updates slightly after the write, so a user may not see their change for a moment. Handle it by reading from the write side right after a write, showing the change optimistically in the UI, or accepting the short delay.
Levels of CQRS
- Simple: same database, separate code paths and models for commands and queries. Cheap and often enough.
- Separate read store: the same data copied into a store tuned for reads.
- Full: different databases, event-driven sync, often combined with event sourcing.
When it fits
- Read volume and shape are very different from writes.
- Complex domain rules on writes, dashboards or search on reads.
- You need to scale reads and writes independently.
When it is overkill
Simple CRUD apps. The extra moving parts, sync bugs and stale reads are not worth it. Start with level 1 and move up only if you need to.
Takeaway: CQRS is a tool for read/write mismatch. Begin with separate code paths, and add a separate read store only when the numbers demand it.
System Design series, Part 2 (building blocks): topic 12 of 14. Previous: Service discovery: how services find each other.
