Distributed Systems

CQRS Explained: Separating Reads from Writes in Complex Systems

Most CRUD systems use one model for both reading and writing data, and that works fine until the two start pulling in opposite directions. CQRS is what happens when you stop forcing them to share.

Published July 6, 2026

Command Query Responsibility Segregation splits an application into two distinct paths: commands, which change state and return nothing but success or failure, and queries, which read state and never change anything. In a typical CRUD app, the same model and often the same database table handle both — an Order class gets both read from and written to through the same schema. CQRS says these two responsibilities have genuinely different requirements and shouldn't be forced to share a representation.

Why the two sides actually want different shapes

A write model for placing an order cares about validity: is this a legal state transition, does the customer have enough balance, is the inventory available. It's naturally normalized, because normalization is what prevents write-side inconsistency. A read model for displaying an order history page cares about none of that — it wants a single denormalized row with the customer's name, the item titles, and the total already joined together, because joining at read time on every page load is wasted work when the same joined shape gets requested constantly. Forcing one schema to serve both jobs means either the write side carries denormalized data it doesn't need for validity, or the read side pays join costs on every request that a dedicated read model wouldn't.

What the split looks like in practice

// command side: validates and mutates
function placeOrder(customerId, items) {
  validateInventory(items);
  const order = Order.create(customerId, items);
  orderWriteStore.save(order);
  publish("OrderPlaced", order);
}

// query side: reads a precomputed, denormalized view
function getOrderHistory(customerId) {
  return orderHistoryReadStore.find({ customerId });
}

The write side persists to its own store, optimized for consistency and validation. When a write succeeds, it publishes an event. A separate process subscribes to that event and updates the read store — often a different database entirely, shaped exactly for the queries the UI actually runs, sometimes duplicated into several read stores each shaped for a different screen.

The trade-off nobody gets to skip: eventual consistency

Because the read store is updated asynchronously in reaction to an event, there's a window, usually milliseconds but sometimes longer under load, where the write has succeeded but the read model hasn't caught up yet. A user who places an order and immediately refreshes their order history might not see it for a brief moment. This is the real cost of CQRS, not the extra code: you're trading immediate read-your-own-write consistency for read models that are fast and exactly shaped for their query. Systems that adopt CQRS need a plan for this gap — often just returning the just-created object directly from the command response so the UI has something to show immediately, rather than making the user re-query the lagging read store.

When it's worth the added moving parts

CQRS adds real operational surface: two models to keep in sync conceptually, an event pipeline connecting them, and a genuine consistency window to reason about and test. That's a bad trade for a small CRUD app where reads and writes are simple and infrequent enough that a shared model was never actually a bottleneck. It earns its cost in systems where read and write load are wildly asymmetric — a product catalog read millions of times for every one write, say — or where the read side needs several very differently shaped views of the same underlying data that would be awkward or slow to produce from a single normalized write schema on the fly.

CQRS doesn't require event sourcing, but they pair well

It's a common misconception that CQRS requires storing every state change as an immutable event rather than just the current row. They're independent decisions: you can build a CQRS system where the write store still just holds current state, updated in place. But if you're already publishing an event on every command for the read model to consume, you're most of the way to being able to persist those events themselves as the source of truth, which is the idea event sourcing builds on.