What CQRS Actually Separates
CQRS stands for Command Query Responsibility Segregation. In a traditional CRUD service, the same model — often the same set of classes and the same database tables — handles both writes (create, update, delete) and reads (get, list, search). CQRS splits this into two distinct models: a command model that validates business rules and applies writes, optimized for correctness and consistency, and a query model that serves reads, optimized purely for the shapes the UI actually needs. These two models can use entirely different schemas, and in many implementations, entirely different databases. The command side might store a normalized relational representation of an order, while the query side stores a fully denormalized 'order summary' document tailored exactly to what a single API endpoint returns, with no joins required at read time.
Cricket analogy: A cricket board's official scoring system (validating every run, wicket, and no-ball against the rules) is the command side, while the flashy graphics package showing win probability and strike rates on TV is a completely separate query-optimized view built from that same underlying data.
Why Split Reads from Writes?
The motivation is that reads and writes have fundamentally different requirements and load profiles in most systems. Writes need strong validation, transactional integrity, and a normalized model that avoids duplication (so a business rule change only needs to be applied in one place). Reads, by contrast, are usually far more frequent — often 10 to 100 times more read traffic than write traffic — and benefit from denormalization, caching, and shapes tailored precisely to each UI screen, since joining normalized tables at read time on every request is expensive at scale. By separating them, you can scale the read side independently (more replicas, aggressive caching, a search-optimized database like Elasticsearch) without touching the write side's transactional guarantees, and vice versa: you can tighten write-side validation without worrying about read performance implications.
Cricket analogy: A stadium sells far more tickets to spectators (reads) than it processes player contract changes (writes), so the ticketing system is built for massive concurrent throughput while the contracts system is built for strict validation and audit trails, each optimized separately.
CQRS with Event Sourcing
CQRS is often paired with event sourcing, though the two are independent patterns and can be used separately. In event sourcing, the command side doesn't store the current state directly — it stores an append-only log of every event that happened (OrderPlaced, ItemAdded, OrderShipped), and the current state is derived by replaying those events. This pairs naturally with CQRS because the event log becomes the single source of truth that multiple read-model projections can be built from independently: one projection builds a fast lookup-by-order-ID view, another builds a customer-lifetime-value aggregate, another feeds a search index — all consumed from the same event stream, each rebuildable from scratch if the projection logic changes. This is powerful but adds real complexity: you need an event store, a way to version events as schemas evolve, and a projection/replay mechanism, so teams should only reach for the combination when the audit trail and multiple-read-model benefits clearly outweigh that operational cost.
Cricket analogy: A ball-by-ball commentary log (every delivery recorded as an event: 'wide', 'four', 'wicket') is the event store, and from that single log you can derive the current score, a wagon-wheel chart, and a bowler's economy rate — three separate read-model projections from one source of truth.
// Simplified CQRS: separate command and query handlers
public record PlaceOrderCommand(Guid CustomerId, List<OrderLine> Lines);
public class PlaceOrderCommandHandler
{
private readonly IOrderWriteRepository _writeRepo;
private readonly IEventPublisher _events;
public async Task Handle(PlaceOrderCommand cmd)
{
var order = Order.Create(cmd.CustomerId, cmd.Lines); // validates business rules
await _writeRepo.Save(order); // normalized write model
await _events.Publish(new OrderPlacedEvent(order.Id, order.CustomerId, order.Total));
}
}
// Separate, denormalized read model updated asynchronously by the event above
public class OrderSummaryProjection
{
public async Task On(OrderPlacedEvent evt)
{
await _readDb.Upsert(new OrderSummaryDocument
{
OrderId = evt.OrderId,
CustomerName = await _customerCache.GetName(evt.CustomerId), // pre-joined
Total = evt.Total,
Status = "Placed"
});
}
}
public class GetOrderSummaryQueryHandler
{
public Task<OrderSummaryDocument> Handle(Guid orderId) =>
_readDb.FindById(orderId); // no joins, single fast lookupCQRS does not require two physical databases — the simplest form is a single database with separate C# or Java classes for commands vs. queries, avoiding a bloated 'God object' model. Reach for physically separate read/write stores only once you have a measured scaling or modeling reason to justify the added operational complexity.
CQRS with separate physical stores means the query model lags the command model by however long event propagation takes — the same eventual-consistency tradeoff sagas and the outbox pattern deal with. A user who just placed an order might briefly see it missing from their order history list until the projection catches up, so design the UI to tolerate or mask that gap.
- CQRS splits a service's write path (commands, validated and normalized) from its read path (queries, denormalized and optimized for the UI).
- The split exists because reads and writes typically have very different volume and shape requirements, letting each scale and evolve independently.
- CQRS is often combined with event sourcing, where an append-only event log is the source of truth and multiple read projections are built from it.
- CQRS does not require two physical databases; the simplest version is just separate command and query classes within one service.
- When paired with physically separate stores, CQRS introduces eventual consistency between the write and read sides, which must be designed for.
- Event sourcing adds real operational complexity — an event store, schema versioning, and replay/projection logic — and should be adopted deliberately.
- CQRS is most valuable when a service has complex business rules on writes and very different, high-volume read patterns that a single model can't serve well.
Practice what you learned
1. What does CQRS stand for and fundamentally separate?
2. Why is the read model in CQRS typically denormalized while the write model is normalized?
3. How does event sourcing typically pair with CQRS?
4. Does CQRS require two physically separate databases?
5. What tradeoff does CQRS with physically separate stores introduce?
Was this page helpful?
You May Also Like
Eventual Consistency Explained
Eventual consistency guarantees that, absent new updates, all replicas or downstream views of data will converge to the same state — but not instantly, which shapes how microservices must be designed.
The Outbox Pattern
The Outbox pattern guarantees a service's database write and its corresponding event publication happen atomically, by writing the event to an 'outbox' table in the same local transaction and relaying it separately.
Database-per-Service Pattern
Each microservice owns and exclusively accesses its own database, preventing hidden coupling through shared schemas and letting teams evolve their data models independently.
The Saga Pattern
The Saga pattern coordinates a business transaction across multiple microservices as a sequence of local transactions, each with a compensating action to undo it if a later step fails.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics