We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Distributed Systems Core
Command Query Responsibility Segregation: using different models for reading and writing data. Reads and writes have different performance needs, so separate them.
In short
CQRS (Command Query Responsibility Segregation) is a design pattern that splits an application into two separate paths: one model that handles writes (commands) and a different model that handles reads (queries). Instead of one shared data model serving both, each side is shaped for its own job, so reads can be denormalized and fast while writes stay validated and consistent.
In short
CQRS (Command Query Responsibility Segregation) is a design pattern that splits an application into two separate paths: one model that handles writes (commands) and a different model that handles reads (queries). Instead of one shared data model serving both, each side is shaped for its own job, so reads can be denormalized and fast while writes stay validated and consistent.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers CQRS across a run of lessons, not one page. These 4 alone are about 97 minutes of step-by-step reading, 2 of them with code you run in the browser, all with a quiz.
Command Query Responsibility Segregation, separate read and write models for different scaling and optimization needs.
Store events instead of state, rebuild any point in time from the log of what happened.
Combine data from multiple sources into a unified view, building the single source of truth.
Route explicit instructions to the one handler responsible for executing them.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with CQRSpay once,
yours for life
In a normal application you have one model, say an Order entity, and the same code reads it and writes it. CQRS breaks that single model in two. A command is an instruction that changes state, like PlaceOrder or CancelOrder. A query is a request that returns data and changes nothing, like GetOrderHistory. The pattern says: handle these with separate models, and often separate code paths, separate services, and even separate databases.
The reason comes down to a mismatch most systems ignore. Writes need validation, business rules, and consistency. They are usually low volume. Reads are often 10x to 100x more frequent, need to be fast, and want data already shaped for the screen that shows it. Forcing both through one model means you either slow down reads with normalized tables and joins, or you weaken your write model to make reads convenient. CQRS lets each side win on its own terms.
CQRS does not require event sourcing, two databases, or any messaging. The simplest version is just two sets of code in the same service hitting the same database: command handlers that run business logic, and query handlers that run plain optimized SELECTs and skip the domain layer entirely. That alone is valid CQRS.
The write side accepts a command, validates it against business rules, and updates the authoritative data store. This is your source of truth. It stays normalized and consistent because correctness matters more than read speed here.
The read side serves queries from a read model that is optimized for display. In the full version, this read model lives in a separate store: a denormalized table, a document in MongoDB, a search index in Elasticsearch, or a cache in Redis. When the write side changes data, it publishes an event, and a projector listens for that event and updates the read model to match.
That last step introduces the most important property to understand: the read model is updated asynchronously, so it is eventually consistent. There is a small window, usually milliseconds, where a user who just wrote data could query the read side and not see their own change yet. Systems handle this by reading their own writes from the write side, or by showing an optimistic UI update until the projection catches up.
When CQRS is paired with event sourcing, the write side stores the full sequence of events rather than just the current state, and read models are built by replaying those events. The two patterns fit together well, but neither requires the other.
CQRS earns its complexity when read and write loads are very different, when the read shape differs a lot from the write shape, or when many different views need the same underlying data. A reporting dashboard, a product catalog with search and filtering, and a high-traffic feed are all good fits.
The cost is real. You now maintain two models, you accept eventual consistency on reads, and if you add separate stores and projections you take on the operational burden of keeping them in sync and handling projector failures. For a simple CRUD app where reads and writes look nearly identical and traffic is modest, CQRS is over-engineering that buys you nothing.
A common middle ground is to apply CQRS to one busy slice of a system rather than the whole thing. You might run plain CRUD for account settings while using full CQRS with a denormalized read store only for the order history view that gets hammered. The pattern is a tool you apply where the read and write mismatch actually hurts, not a rule you apply everywhere.
Picture an e-commerce checkout. When a customer places an order, the command handler validates stock, charges the card, and writes a normalized order row plus line items into PostgreSQL. That write path enforces every rule and is the source of truth.
Now the customer opens their order history page. That query does not touch the order tables or run six joins. It reads from a denormalized read model, one row per order with the product names, total, and status already flattened in, served from a read replica or a cache. The page loads in a few milliseconds even under heavy traffic.
Keeping the two in sync is the job of a projector. When the order is written, an OrderPlaced event fires, a background worker picks it up, and it upserts the flattened row into the read store. If the worker lags by 50 milliseconds, the history page might briefly miss the newest order, which is an acceptable trade for a read path that scales independently of the write path.
Microsoft eShopOnContainers
Microsoft's reference microservices app uses CQRS in its Ordering service: full domain model for commands, lightweight Dapper queries for reads.
Netflix
Splits write paths from read-optimized stores and serves many denormalized read views from data shaped for each UI surface.
Redis
Commonly used as the read-side store in CQRS, holding denormalized projections that serve queries in sub-millisecond time.
Elasticsearch
A frequent CQRS read model: the write side stays in a relational DB while a projector keeps a search-optimized index in sync.
No. The simplest CQRS just uses two code paths against one database: command handlers with business logic and query handlers running plain optimized reads. Separate stores are an optional escalation for when read and write loads need to scale independently.
No, they are different patterns that often appear together. Event sourcing stores state as a sequence of events. CQRS separates read and write models. You can use either one without the other, though combining them is popular because events make it easy to build read projections.
Complexity and eventual consistency. You maintain two models instead of one, and when you use separate read stores the read side lags the write side by a short window, so a user might not immediately see their own change on the read path.
Skip it for simple CRUD apps where reads and writes have nearly the same shape and traffic is modest. The extra models and consistency handling add cost without payoff when there is no real read and write mismatch.
The write side publishes an event after each change, and a projector subscribes to that event and updates the read model. This happens asynchronously, which is why the read side is eventually consistent rather than instantly in sync.
Event Sourcing
Store events instead of state, rebuild any point in time from the log of what happened
Data Aggregation
Combine data from multiple sources into a unified view, building the single source of truth
Command Bus
Route explicit instructions to the one handler responsible for executing them
Event-Driven Architecture
Build systems where everything reacts to events, the architecture powering Netflix, Uber, and LinkedIn at massive scale
Command Pattern
Encapsulate requests as objects, enabling undo, queuing, logging, and distributed task execution
Event Sourcing
Storing every state change as an immutable event instead of just the current state. You can rebuild any past state by replaying events.
Saga Pattern
A way to manage distributed transactions across microservices using a sequence of local transactions with compensating actions for rollback.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
CAP Theorem
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
Consensus
The process of getting multiple nodes in a distributed system to agree on a single value. The foundation of distributed databases and coordination services.
Paxos
A family of protocols for solving consensus in unreliable networks. Famously difficult to understand but mathematically proven correct.
This page explains the idea. The "CQRS" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the CQRS lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about CQRS in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
