CQRS (Command Query Responsibility Segregation) is a pattern, coined by Greg Young, that lifts Bertrand Meyer's Command Query Separation from methods to models: writes and reads go through separate models, each optimized for its purpose. Domain events can propagate changes from the write side to read-side projections, with the read model allowed to lag behind so that both sides can scale independently. Event sourcing complements CQRS but is not required.

CQRS (Command Query Responsibility Segregation)

Details
Also known as

CQS at architectural scale

Core Concepts:

Command Query Separation (CQS)

Bertrand Meyer’s principle — methods either change state (commands) or return data (queries), never both

Commands

Write operations that change state and return void; represent intent as immutable command objects

Queries

Read operations that return data with no side effects; safe to retry and cache

Separate read/write models

Independent data models optimized for their respective purpose

Eventual consistency

Read model may lag behind write model; acceptable trade-off for scalability

Event-based synchronization

Domain events propagate changes from write side to read side projections

Independent scalability

Read and write sides can be scaled, deployed, and optimized independently

Event sourcing optional

CQRS does not require event sourcing; the patterns are complementary but independent

Key Proponents

Greg Young (coined CQRS), Bertrand Meyer (CQS origin, "Object-Oriented Software Construction", 1988), Udi Dahan

When to Use:

  • Systems with asymmetric read/write workloads

  • Complex domains where read and write models diverge significantly

  • Event-sourced systems requiring materialized views

  • High-performance systems needing independent scaling of reads and writes

  • Collaborative domains with task-based UIs

Criticism:

  • Martin Fowler, bliki: CQRS — warns that "for most systems CQRS adds risky complexity", a "significant mental leap" that pays off only in specific bounded contexts, not as a default pattern

  • Udi Dahan, one of CQRS’s main proponents, opens "When to avoid CQRS" (2011) with "Most people using CQRS (and Event Sourcing too) shouldn’t have done so" — and adds that CQRS "should not be your top-level architectural pattern"

  • Greg Young himself pushed back on scope creep in "CQRS is not an Architecture" (2012, archived): CQRS is a pattern applied inside a single component, not an architectural style for a whole system