CQRS Explained

Analogy categoryAnalogies

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.

csharp

// 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 lookup

CQRS 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.