A live platform's read requirements differ sharply from its write model. What evidence justifies CQRS, and what obligation does it create?
Show the full answer Hide the answer
The evidence required
1. The read query cannot be served acceptably from the write model after optimisation — indexes, denormalisation, materialised views and caching all tried and measured. "Would be nicer" is not evidence.
2. Read and write workloads have genuinely different scaling requirements, such that scaling them together is materially wasteful.
3. The staleness is explicitly acceptable to whoever owns the customer experience, and the interface tells the truth about it.
4. A rebuild path exists and has been exercised. If a projection can be corrupted and cannot be regenerated within an acceptable window, the read model has quietly become an unreliable system of record.
The obligation it creates
A projection that can be silently wrong, which is worse than an outage because nothing alerts. The system is up, serving, and returning incorrect data.
That obligation is met by four specific practices:
- A stated freshness SLO, so staleness is a property rather than a surprise.
- Lag monitoring and alerting — not pipeline health. A projection process that is running, connected and forty minutes behind passes every liveness check while serving wrong data.
- A rebuild path that has been drilled, not merely designed.
- An explicit correctness boundary: decisions with consequences are validated against the source of truth, never against the projection. The read model informs; it does not decide.
The framing that usually applies
Most platforms with a search index fed asynchronously from a transactional store are already doing CQRS. The proposal is frequently not "adopt CQRS" but "acknowledge and formalise what exists" — name the freshness SLO, monitor lag, build and exercise the rebuild, and handle the failure modes deliberately.
That reframing matters because the complexity is already being paid, without the observability and rebuild capability that make it safe.
The cheaper counter-proposal
If the driver is one expensive query rather than a whole read workload, a database-maintained materialised view delivers most of the benefit with no pipeline: the database keeps it coherent and staleness is bounded by refresh policy.
Reach for full asynchronous CQRS when the read store must be a genuinely different technology — a search engine, a time-series store, a graph — because that is when no database feature can bridge the gap.