When would you actually use CQRS?
“A team wants to introduce CQRS for their SaaS product. What problem must exist for that to be a good decision, and what will it cost them?”
What this tests
- CQRS as a response to a measured mismatch between read and write shapes
- The cost: eventual consistency between models, projections, two models to maintain
- CQRS-lite as the usual right answer
- Read-after-write handling in the UI
Answers by level
Read the beginner answer first and notice what is missing.
CQRS pays off when the write model and the read model genuinely want different shapes: writes are normalised and validated per aggregate, while the dashboard needs a denormalised view joining eight tables, or reads outnumber writes 100:1 and need a different store (Elasticsearch, a Redis projection). Without that mismatch, it is two models to keep in sync for no gain.
The cost is eventual consistency: a command updates the write model, an event updates the read model some milliseconds to seconds later, and a UI that reads its own write immediately sees stale data. You also inherit projection rebuilds, schema evolution across two models, and a new failure mode ("the projector is 20 minutes behind"). Most teams should start with CQRS-lite: separate read queries and DTOs against the same database, no async projection — see CQRS.
Green flags · Red flags
- Demands a measured read/write mismatch before adopting it
- Names eventual consistency and projection lag as the price
- Recommends CQRS-lite (separate queries, same DB) as the first step
- Has a read-your-writes strategy
- Separates CQRS from event sourcing
- "CQRS is a best practice for scalable systems, so we should use it from day one."
- Assumes CQRS implies event sourcing
- No answer for read-after-write staleness
- Cannot say what a projection rebuild costs