CQRS (Command Query Responsibility Segregation)
CQRS separates the command (write) model from the query (read) model so each can be optimized and scaled independently, at the cost of added complexity.
CQRS, or Command Query Responsibility Segregation, is a design pattern that splits an application's data handling into two distinct paths: one for commands that change state and one for queries that read state. Each path can use its own model, storage, and scaling strategy.
How It Works
In a traditional design, the same data model serves both reads and writes. CQRS breaks this apart. The write side accepts commands, validates business rules, and persists changes through a model shaped for consistency and correctness. The read side serves queries from one or more read models — often denormalized projections tuned for fast retrieval. The two sides may share a database or use separate stores kept in sync, frequently through events. When stores are separate, the read side is typically eventually consistent: it catches up shortly after a write.
Why It Matters
Reads and writes often have very different requirements. Reads may be far more frequent and benefit from caching and denormalization, while writes need strict validation and transactional integrity. CQRS lets each side evolve and scale on its own terms. It pairs naturally with event sourcing, where the write side emits events that build the read projections.
The cost is added complexity. Two models must be maintained, and eventual consistency complicates user experience and testing. CQRS is best applied selectively to subsystems with genuine read/write asymmetry, not as a blanket architecture.
Related Terms
Event sourcing frequently feeds CQRS read models. Domain-driven design provides the bounded contexts where CQRS is applied. Event-driven architecture carries the updates between sides.