CQRS

CQRS, command query Responsibility Segregation, is a realization pattern that separates the write side that interprets commands and persists authoritative change from the read side that answers queries by reconstituting queryable observations.

The broader forces, cross-realm bundle, preservation conditions, and catalog provenance belong to CQRS as an architecture practice. This note focuses on the realization family and its operational consequences.

In the Cohesive System Model, CQRS can be understood as a separation of persistence and reconstitution:

The command side interprets input as commands relative to an observer, boundary, current entity state, invariants, policies, authority, and expected version.
Transition evaluation produces a typed decision with a sparse patch, outcome, emissions, and guarantee demands; it does not itself commit state.
Accepted transition decisions commit authoritative state changes, often as current-state records, event-sourced persistence events, or transactional writes.
The query side interprets input as queries and reconstitutes read-oriented observations through projections, indexes, materialized views, caches, or derived state.

CQRS does not require event sourcing. Event sourcing is one possible write-side persistence strategy. CQRS can also use current-state records, relational tables, documents, actor state, workflow state, or other persistence mechanisms.

The separation is useful because command handling and query answering often have different shapes:

Commands require interpretation, validation, authority, invariants, and concurrency control.
Queries require efficient observation, projection, filtering, indexing, aggregation, and access control.
Write models usually protect semantic consistency.
Read models usually optimize visibility and access patterns.

Consistency under Asynchrony

CQRS often updates read models asynchronously from the write side. That creates operational concerns that must be explicit:

Projection lag: a committed write may not be visible to a query immediately.
Read-your-writes: a caller may need a way to observe its own committed change.
Monotonic reads: a caller may need to avoid seeing older projection versions after newer ones.
Ordering scope: projection updates may be ordered per entity, stream, partition, tenant, or process, not globally.
Idempotency: projection updates may be delivered more than once.
Rebuild and recovery: read models must be rebuildable or otherwise recoverable from authoritative persistence.
Acknowledgment meaning: command success means the write-side transition committed, not necessarily that every read model has caught up.

The consistency question is therefore boundary-relative. A command boundary may be strongly consistent while a query boundary is eventually consistent. A projection may be current for one entity and stale for another. A UI, API, process, or downstream observer must know which boundary its observation comes from and what freshness guarantee applies.

Command-side interpretation may use a finite sparse observation rather than fully materialized entity state. Unobserved, absent, null, unknown, failed, and concrete paths must remain distinct. Every observation that influenced the decision must retain the required freshness or consistency through the commit boundary.

Relationship to Event Sourcing

Event sourcing and CQRS are often combined but remain distinct.

command -> transition decision -> committed state or persistence-event history
                         -> projections/read models
                         -> queries

In this combined pattern, event sourcing supplies the committed event history, while CQRS separates command-side consistency from query-side reconstitution. The read side must still handle asynchronous projection, ordering, idempotency, and recovery.

External References

Martin Fowler, CQRS, 2011.
Greg Young, CQRS Documents, 2010. See also the CQRS Documents page.
Microsoft Azure Architecture Center, CQRS pattern.