Command-Query Responsibility Allocation
CQRS allocates the command (write) and query (read) sides to separate models, so each can be optimized for its workload without forcing one model to serve both a normalized write and a.
Definition
Command-Query Responsibility Allocation is the architectural pattern where the write model (commands, aggregates, business rules) and the read model (projections, denormalized views, query optimization) are separate, communicating through events, so that each side scales and evolves for its own workload.
Context and scope
Applied in high-read systems, event-sourced domains, and any context where the read shape differs radically from the write shape and a single model compromises both.
Common misconceptions
- CQRS requires event sourcing — event sourcing is one way to feed the read model; CQRS can use change-data-capture or synchronous projection updates
- CQRS is always more scalable — it adds complexity; it scales when the read and write workloads differ enough to justify two models
Anti-patterns
- Introducing CQRS to a CRUD domain where the read and write shapes match, paying the complexity for no gain
- Projecting the read model synchronously in the same transaction, reintroducing the coupling CQRS was meant to remove
Related concepts
Authoritative source
What it is
Command-Query Responsibility Allocation is the architectural pattern where the write model (commands, aggregates, business rules) and the read model (projections, denormalized views, query optimization) are separate, communicating through events, so that each side scales and evolves for its own workload. Applied in high-read systems, event-sourced domains, and any context where the read shape differs radically from the write shape and a single model compromises both. The organizing principle is which decisions are hard to reverse and should be made once, versus which are easy to reverse and should be deferred.
How it works
Boundaries are drawn along axes of change: things that change together are colocated, things that change independently are separated by interfaces whose contracts are explicit and versioned. Dependencies point toward stability — domain logic depends on abstractions, infrastructure depends on domain, never the reverse. The structure makes the system’s intent legible without reading every module.
When to choose and pitfalls
Choose this structure when the system will outlive its first deployment and face requirements you cannot now predict. The pitfall is premature abstraction — adding indirection for a flexibility that never materializes, paying its complexity cost forever. The opposite pitfall is entangling concerns that later need to separate, forcing a rewrite instead of a refactor.