Skip to content

CONCEPT Cited by 1 source

CQRS (Command-Query Responsibility Segregation)

CQRS — Command-Query Responsibility Segregation — is the idea that the data model optimized for accepting writes (commands) doesn't have to be the same data model serving reads (queries). The write model is typically normalized, strongly consistent, and optimized for focused updates; the read model is typically denormalized, pre-computed, and optimized for the queries the application actually runs. A pipeline (often async) projects writes from the command model into one or more query models.

Why the split matters

Many systems meet a tension where one data shape is hostile to the other:

  • Operations-friendly shape (normalized relational with lots of entities + joins) is great for small edits, audit, constraints, but expensive to read in bulk.
  • Read-friendly shape (denormalized, pre-joined, indexed by the query dimension — e.g., a pre-built graph, a materialized aggregate, a wide search doc) is fast to serve but awkward to edit in-place.

CQRS lets both exist and keeps each optimized for its job. The read model is a derived artifact — losing it is tolerable because it can be rebuilt from the write model (the source of truth).

Shapes seen in the wild

  • Async-projected read model — writes go to the command store; a pipeline reacts and rebuilds / updates the read store. Read store can be a different technology entirely. (Canva print routing: relational DB → async rebuild → Redis graph; see patterns/async-projected-read-model.)
  • OLTP + OLAP — the warehouse as a derived read model for analytical queries. Canva's billing counting pipeline does this too (DynamoDB → Snowflake → RDS for serving). See concepts/oltp-vs-olap, concepts/elt-vs-etl.
  • Materialized views — the RDBMS version of the same idea, kept in-engine.

Consistency model

The projection is usually eventually consistent — there's a lag between write and read-model update. Some systems bound this with versioned reads, others accept it and advertise freshness. CQRS doesn't require strong consistency, but it doesn't forbid it either; the read model can block on the projection if the application can afford the latency cost.

Seen in

  • sources/2024-12-10-canva-routing-print-orders — relational operations DB is the source of truth; async reactive pipeline rebuilds layered routing graphs to Redis; reactive rebuild triggers on relevant relational writes.
  • — CQRS as an organizational split, not just a data split. Zalando's PODS program restructured the Product department into two stream-aligned teams along CQRS lines: Partners & Supply (command-side, data ingestion) and Product Data Serving (query-side, aggregation/retrieval via PRAPI). The post cites Fowler's CQRS bliki and Conway's Law directly as the justification. The framing treats CQRS as required for the architectural change — without clear Product-data stewardship on the query side, the ~350-consumer-team migration off event-subscription local stores wouldn't have been executable. Canonical wiki instance of CQRS-as-team-topology.
Last updated · 542 distilled / 1,571 read