CQRS
Separate the model used to read data (Query) from the model used to write data (Command) — each optimised independently.
★★★★★4/5Inside a codebase — classes, modules, files
Interactive visualization
LiveCommand (Write)
Query (Read)
Write DB — normalised
| id | name | orders | ts |
|---|---|---|---|
| 1 | Alice Chen | 3 | 09:01 |
| 2 | Bob Smith | 1 | 09:05 |
Read DB — denormalised
| id | displayName | orders | status |
|---|---|---|---|
| 1 | Alice Chen | 3 | active |
| 2 | Bob Smith | 1 | active |
Drag the Lag slider higher to see eventual consistency in action — the Write DB updates immediately, the Read DB catches up later.
How it works
Command Query Responsibility Segregation (CQRS), popularised by Greg Young, splits a system's data model into two paths. Commands mutate state and return nothing (or just an ID). Queries read state and never mutate it.
This allows the write side (optimised for transactional integrity) and read side (optimised for query performance) to evolve independently. Read models are often denormalised projections kept up-to-date via events from the write side.
CQRS pairs naturally with Event Sourcing — the write side publishes events that the read side uses to build projections.
Why it matters
In high-traffic systems, reads vastly outnumber writes. CQRS lets teams optimise each path independently — e.g. a normalised write store and multiple denormalised read stores per use case.
✓ When to use
- →Read/write ratio heavily skewed (e.g. social media timelines)
- →Complex domain logic on write side that shouldn't pollute queries
- →Paired with Event Sourcing for full audit trail
- →Multiple representations of the same data for different consumers
✗ When NOT to use
- →Simple CRUD apps — CQRS adds overhead with no benefit
- →Small teams without capacity to maintain two models
- →Strong consistency requirements on every read after write
Trade-offs
Read and write models can be optimised independently
Eventual consistency between write and read stores
Complex command logic isolated from query logic
More code — two models, two data stores, synchronisation logic
In production
Azure Event Grid and Cosmos Change Feed enable CQRS projections
CQRS+ES framework used by banks and insurance companies
Industry adoption
Related principles
Event Sourcing
LiveStore state as an immutable log of events rather than the current snapshot — rebuild state by replaying events.
Event-Driven Architecture
LiveServices communicate by producing and consuming events asynchronously through a central event bus or message broker.
Domain-Driven Design
Model software around the core business domain using a shared language between developers and domain experts.