We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Distributed Systems Core
Free preview: the first 2 parts of this 11-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Distributed Systems Core
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Think about a library. The process of adding a new book to the collection (cataloging, assigning a Dewey decimal number, placing it on the correct shelf) is completely different from the process of finding a book (searching the catalog, browsing by subject, checking availability). The skills are different. The tools are different. The people doing it might even be different departments.
Yet most software systems use the same data model for both reading and writing. The same database schema. The same entity classes. The same API endpoints. This works fine for simple CRUD applications. But at scale, reads and writes have radically different performance characteristics, optimization strategies, and scaling needs.
An e-commerce product page is read millions of times per day but updated a few times per week. The read pattern needs denormalized data (product details, reviews, pricing, availability, all on one page). The write pattern needs normalized data (update the price in one place, not 50 denormalized copies). Using one model for both means either reads are slow (too many JOINs) or writes are error-prone (updating denormalized data in multiple places).
CQRS. Command Query Responsibility Segregation, says: stop pretending reads and writes are the same thing. Build a write model optimized for accepting and validating commands, and a separate read model optimized for serving queries. Keep them in sync via events.
Greg Young formalized CQRS in 2010, building on Bertrand Meyer's CQS (Command-Query Separation) principle from the 1980s. Today it's the architectural backbone of systems at companies like Microsoft, Uber, and any team using .
Command side (Write Model):
Query side (Read Model):
The bridge: Events. When the write model processes a command, it publishes an event. The read model subscribes to these events and updates its denormalized views. The read model is a projection of the write model, a view optimized for specific query patterns.
| Aspect | Command (Write) Side | Query (Read) Side |
|---|---|---|
| Data model | Normalized, domain-rich | Denormalized, view-optimized |
| Database | Relational, strong consistency | Document store, materialized views, search index |
| Scaling | Moderate (fewer writes) | Aggressive (many reads, replicas, ) |
| Validation | Full business rule validation | Minimal (data is pre-validated) |
| Can be higher (consistency matters) | Must be low (user experience) |
The key trade-off: eventual consistency. The read model updates asynchronously via events. Between a write completing and the read model being updated, there's a window (milliseconds to seconds) where the read model is stale. This is the fundamental cost of CQRS, you trade immediate consistency for independent scalability.