CQRS
CQRS (Command Query Responsibility Segregation) is an architectural pattern that separates the operations that change data (commands) from the operations that read data (queries) into distinct models, often backed by different data stores.
Definition
CQRS (Command Query Responsibility Segregation) is an architectural pattern that separates the operations that change data (commands) from the operations that read data (queries) into distinct models, often backed by different data stores.
Overview
In a traditional CRUD design, the same model is used to read and write data. CQRS splits this into two paths: a command model optimized for validating and persisting writes, and a query model optimized for fast, flexible reads — often a denormalized or pre-aggregated view built specifically for how the UI needs the data. This separation lets each side scale and evolve independently. CQRS is frequently paired with Event-Driven Architecture and event sourcing: instead of overwriting a row when state changes, the system appends an event describing the change, and the query-side read models are built (and rebuilt) by replaying or projecting those events. This gives a full audit trail and lets teams create new read models later without touching the write path. It is also common within a Microservices system, where the command service and query service can be deployed and scaled separately. The pattern adds real complexity — two models to maintain, eventual consistency between the write side and the read side, and more infrastructure to operate, sometimes fronted by an API Gateway that routes commands and queries to their respective services — so it is generally reserved for subsystems with genuinely different read and write scaling needs or complex domain logic, such as high-throughput trading systems or collaborative applications, rather than applied uniformly across an entire application.
Key Concepts
- Separate models for commands (writes) and queries (reads)
- Read models can be denormalized and optimized purely for query performance
- Often paired with event sourcing to derive read models from an event log
- Write and read sides can be scaled and deployed independently
- Introduces eventual consistency between the command and query sides
- Enables building multiple specialized read models from the same source of truth
- Best suited to subsystems with complex domain logic or asymmetric read/write load