CQRS

Command Query Responsibility Segregation splits a system’s model in two: one model handles the commands that change state, a different model answers the queries that read it. Martin Fowler, attributing the idea to Greg Young, puts it as the notion that “you can use a different model to update information than the model you use to read information”.

Applied to services designed around aggregates, the split falls out naturally:

1. Service APIs that perform write actions against an aggregate.
2. Service APIs that perform read queries, served from a model shaped for reading.

What the separation buys

A single model has to satisfy both jobs at once, and the jobs pull in opposite directions. Writes want a normalised model with invariants enforced in one place; reads want whatever shape the screen needs, joined and denormalised ahead of time. A model that compromises between the two usually serves neither well.

Separating them means:

• The read side can be denormalised, cached, indexed differently or stored in a different engine entirely, without weakening any write-side invariant.
• Reads and writes can be scaled independently, which matters when the ratio between them is lopsided — and it usually is.
• The write model can stay small and strict, because it no longer has to carry fields that exist only to be displayed.

What it costs

The read model is updated from the write side, usually by consuming the events the write side publishes, so it is eventually consistent with it. Everything downstream must tolerate that gap: a user who submits a change and immediately re-reads may not see it. Dealing with that honestly — in the API contract and in the UI — is the bulk of the work CQRS creates.

Fowler is explicit that this is a pattern to be cautious about. Most information systems fit the ordinary model, where data is updated in the same shape it is read, and adding CQRS to one of those adds significant complexity for nothing. It is applied to the specific part of a system whose read and write loads genuinely diverge, never to a whole system by policy.

CQRS and Event Sourcing are frequently introduced together, and each is usable without the other. Adopting both at once doubles the amount of novelty a team has to absorb, so it is worth being deliberate about whether both are needed.

Further reading

• CQRS — Martin Fowler’s definition, and his caution about where it applies