One model is not always enough
In a classic design, one model handles both writes and reads. Command Query Responsibility Segregation separates them into a command side that changes state and a query side that returns data.
The two sides
- Commands express intent such as place order. They validate rules and produce changes. They do not return data beyond an acknowledgement.
- Queries return data and never change state. They can be shaped exactly for each screen.
Each side can use a different model, a different store, and a different scaling strategy. Reads often vastly outnumber writes, so the query side can be replicated and cached independently.
How they connect
The command side typically emits events. The query side consumes them and updates read models tuned for fast lookups.
When to use it
CQRS shines when read and write workloads differ sharply or when complex queries fight against a write optimized model. It adds moving parts, so avoid it for simple crud.
Key idea
CQRS separates the command side that changes state from the query side that reads it so each can be modeled and scaled independently.