What is CQRS (Command Query Responsibility Segregation)?

CQRS (Command Query Responsibility Segregation) is the architectural pattern that separates the write model, the part of the system that receives and validates the operations that change data, from the read model, the part of the system built to answer queries as quickly as possible. In a conventional architecture the same structure serves both whoever enters an order and whoever looks it up in a dashboard; with CQRS commands and queries become two distinct responsibilities, each free to evolve on its own. The idea takes Bertrand Meyer's principle that an operation either changes state or returns data, never both, and carries it from the single method to the whole architecture. Greg Young was the first to describe it, and Martin Fowler, in the most cited reference on the subject, warns that for most systems CQRS adds risky complexity.

See also: Event-driven architecture (EDA) · Services exchanging facts that already happened through a broker, instead of calling each other directly and synchronously.

When eventual consistency is worth the price

CQRS pays off in three situations: when writes and reads carry very different loads, when the domain logic on writes is complex while reads need different shapes of the data (one view for the operator, one for reporting, one for an API), or when operational data has to be queried as quickly as a materialized view without slowing down whoever writes. The read model is usually updated asynchronously, through events published by the write side, as in an event-driven architecture, or through change data capture. The price is eventual consistency: the read side shows the state with some delay, and the two models converge soon but not at the same instant. An order just confirmed can be missing from the dashboard for a few seconds, and whoever uses that data has to be told before release. CQRS does not require event sourcing, which stores every change as a sequence of events instead of the final state: the two patterns often travel together, but the write side can remain an ordinary relational database.

An enterprise example

An SME runs an order-management system on a single database that serves both order entry by operators and executive reporting on sales and margins. At month end the sales report over the full history fires heavy aggregation queries, and order entry slows down on exactly the days when orders peak. A read model dedicated to reporting, updated a few minutes behind, removes the contention: operators work without stalls and the sales team accepts figures a few minutes old, because no decision depends on that window.

Why it matters for decision makers

In an application that only creates, reads and updates records, run by a small team, CQRS is almost always a mistake: it doubles the models to maintain, adds a synchronization to monitor and brings eventual consistency where nobody asked for it. Fowler recommends using it only on specific portions of a system, a single bounded context, never on the whole. Before approving it, the useful question is which performance or complexity problem already exists today, and whether a simpler solution would solve it just as well.