CQRS stands for Command Query Responsibility Segregation, a design pattern that Martin Fowler describes in his bliki and credits to Greg Young: “It’s a pattern that I first heard described by Greg Young.” At its core, Fowler writes, “is the notion that you can use a different model to update information than the model you use to read information.” Most systems use a single conceptual model for both reading and writing data; CQRS deliberately splits that model in two.
The split follows the long-standing distinction between commands and queries. A command changes state but returns no data; a query returns data but changes nothing. CQRS elevates that distinction to an architectural boundary: a command model (the write side) handles updates and enforces the rules and invariants of the domain, while a query model (the read side) handles fetching and displaying information, often shaped specifically for the screens and reports that need it. Fowler notes these can be “different object models, probably running in different logical processes, perhaps on separate hardware.”
Separating the two sides can pay off when the read and write workloads are genuinely different in shape or scale. A system might receive a trickle of complex, validation-heavy writes but serve a torrent of varied reads; with CQRS the read side can be optimized, denormalized, and scaled independently of the write side, and each model stays simpler because it has only one job. The read model is frequently kept up to date by reacting to events emitted by the write model, which is why CQRS appears so often in event-driven discussions.
Fowler is notably cautious about the pattern. He warns that “for most systems CQRS adds risky complexity,” and that it should be reserved for specific bounded contexts where the benefits clearly justify the added sophistication. Keeping two models in sync introduces eventual consistency, more moving parts, and more ways to go wrong; applying CQRS to a whole system by default tends to make ordinary work harder rather than easier.
CQRS is conceptually independent of event sourcing, though the two are commonly combined: an append-only event log naturally feeds one or more read models projected from those events. Understood narrowly — as the deliberate separation of the write model from the read model in the parts of a system that need it — CQRS is a sharp tool for a particular kind of complexity, and a liability when reached for reflexively.