Learn the vocabulary of splitting an application into a command model for writes and a separately optimized model for reads.
0 / 5 completed
1 / 5
A teammate explains that an application uses one model to handle commands that change state and a completely separate, independently optimized model to serve queries that read state, rather than funneling both reads and writes through a single shared model. What architectural pattern is being described?
Command Query Responsibility Segregation, or CQRS, is exactly this: commands that change state are handled by one model, often optimized for validation and consistency, while queries that read state are served by a separate model, often a denormalized read store optimized purely for fast lookups, rather than forcing both concerns through a single shared model. A DNS zone transfer is an unrelated concept about replicating name server records. This split-write-model-from-read-model approach is exactly why CQRS lets each side be scaled and optimized independently.
2 / 5
During a design review, the team adopts CQRS for a product catalog service, specifically so the read side can be a denormalized, heavily cached model optimized for fast search, while the write side stays normalized and focused on validation. Which capability does this provide?
CQRS here provides independent optimization and scaling of reads versus writes, since the read model and write model can each use whatever storage shape and caching strategy best fits their very different access patterns, letting the read side be denormalized and heavily cached for fast search while the write side stays normalized for validation. Forcing both search queries and catalog updates through one shared normalized model means neither side can be optimized without compromising the other. This split-and-optimize-independently behavior is exactly why CQRS is favored when read and write access patterns diverge sharply.
3 / 5
In a code review, a dev notices a product catalog service runs every search query against the same normalized, write-optimized model used for catalog updates, causing search queries to require expensive joins, instead of maintaining a separate denormalized read model as CQRS would suggest. What does this represent?
This is a missed CQRS opportunity, since a separate denormalized read model would let search queries avoid expensive joins instead of sharing the write-optimized model. A cache eviction policy is an unrelated concept about discarded cache entries. This shared-model-for-reads-and-writes pattern is exactly the kind of performance gap a reviewer flags once read and write access patterns diverge.
4 / 5
An incident report shows search latency spiked under load because every search query ran expensive multi-table joins against the same normalized model used for catalog writes, and that model was never optimized for read-heavy access patterns. What practice would prevent this?
Adopting CQRS lets search queries run against a separate, denormalized read model optimized for fast lookups instead of the write-optimized normalized model. Continuing to run every search query against the same normalized write model regardless of how much join overhead that adds under load is exactly what caused the latency spike described in this incident. This separate-optimized-read-model approach is the standard fix once shared-model joins are confirmed to be the bottleneck.
5 / 5
During a PR review, a teammate asks why the team reaches for CQRS instead of just adding more indexes to the single shared model, given that adding indexes avoids introducing a second model to keep in sync. What is the reasoning?
CQRS trades the complexity of keeping a separate read model eventually synchronized for read and write sides that can each be optimized and scaled independently, while adding indexes to a single shared model avoids a second model but still couples read performance to write-side schema constraints. This is exactly why CQRS is favored when read and write access patterns diverge sharply enough to need independent optimization, while adding indexes remains acceptable when a single shared model can still serve both reasonably well.