CQRS (Command Query Responsibility Segregation) is an architectural pattern that splits a system's write path (commands that change state) from its read path (queries that return state), so each side can be modeled, scaled, and optimized independently. It is frequently paired with event sourcing and separate read models to support high-throughput, event-driven systems.
CQRS
CQRS (Command Query Responsibility Segregation) is an architectural pattern that separates the model used to change data from the model used to read it. Instead of one representation serving both writes and reads, commands flow through one path that mutates state and queries flow through another that returns it, each free to use its own schema, storage, and scaling strategy. It builds on Bertrand Meyer’s older command-query separation principle and was popularized as a distinct pattern by Greg Young and Martin Fowler.
- Commands vs. queries - Commands express intent to change state and return no data; queries return data and never change state.
- Independent read and write models - The two sides can use different data structures, databases, and consistency guarantees tuned to their own load.
- Event sourcing affinity - CQRS pairs naturally with event sourcing, where the write side emits events and the read side projects them into query-optimized views.
- Eventual consistency - Because read models are derived from writes asynchronously, teams must design for the lag between a command and its visibility in a query.
In API design CQRS shows up when a provider exposes distinct command and query surfaces - for example write endpoints that accept intent-named operations and separate, heavily-cached read endpoints or materialized views. It is a deliberate trade: you accept added complexity and eventual consistency in exchange for read and write paths that scale on their own terms, which is why it tends to appear in event-driven, high-throughput, and microservice-heavy systems rather than in simple CRUD APIs.
