CQRS

The order write path needs orders, order_items, payments in third normal form with foreign keys and invariants: an order cannot have a negative total; an item cannot reference a missing SKU. The order *page* needs the order, its items with product names and images, the payment status, the shipment tracking number and the customer's display name — a six-table join, run every time the user refreshes, and by support staff, and by the mobile app, ten thousand times for every order created. The same Normalization: 1NF to BCNF that keeps writes correct makes reads expensive, and the Denormalization on Purpose that would make reads cheap makes writes risky. Indexes, caching and read replicas (Replication and Read Scaling) push this a long way — far enough for most systems.

CQRS is the next step when they are not enough: keep the write model normalised and authoritative, and maintain one or more read models — precomputed, denormalised documents shaped exactly like the screens that read them — updated from the write model's events. Commands (PlaceOrder, CancelOrder) go to the write side and are validated there. Queries (GetOrderPage, ListMyOrders) go to a read side that never joins anything because the join was done once, at write time.

Three things change once reads have their own model. Shape: the read model is a document per screen — order_page:{orderId} holding everything the page shows, or a my_orders list per customer already sorted. No joins, no N+1, one key lookup. Scale: reads and writes scale independently; the read store can be replicated to ten nodes or held in Redis (Redis: Data Structures, Not a Cache) while the write database stays a single strongly consistent primary. Storage: the read model can live in a different kind of store — a search index for full-text, a wide-column store for time series, a cache for hot keys — chosen per query rather than compromising one database for all of them.

The projector is a consumer of the write model's events (Event-Driven Architecture), delivered through an outbox so no state change is lost (Distributed Transactions). It is idempotent — it upserts documents keyed by id and ignores events older than the document's version — because it will see duplicates. Several projectors can feed several read models from the same events; adding a new screen means adding a projector, not touching the write model.

The read model is eventually consistent with the write model. After PlaceOrder returns, the projector has not necessarily run; a client that immediately queries GetOrderPage may see the old state or nothing — the read-model-shows-stale-order challenge. The lag is normally milliseconds, but it is unbounded under backlog, and the UI must be designed for it: return the new state in the command response, redirect with the id and show a "processing" placeholder, read-your-own-writes by routing the user's next query to the write model for a few seconds, or wait until the projection version ≥ the command's version. Pretending the lag is zero is the bug.

Projection rebuilds: a bug in the projector or a new field on the screen means rebuilding the read model from scratch — from an event log if you keep one (Event Sourcing), or from the write database by re-reading everything. That needs a rebuild path that runs alongside live traffic and swaps atomically. Two models to maintain: every domain change is now a write-model change, an event change, a projector change and a read-model change, with versioning between them. And debugging spans an asynchronous boundary: "the page shows the wrong total" may be the command, the event, the projector, or a duplicate applied out of order.

CQRS as a *principle* — separate the code that handles commands from the code that handles queries — costs nothing and improves any codebase: a PlaceOrderHandler that validates and writes, and an OrderQueries module with hand-written SQL that joins whatever the screen needs, reading from the same database (or its read replica). No events, no projector, no lag, no rebuild. Add a cache in front of the hot queries (Caching Architecture). This is where the vast majority of applications should stop, and it captures most of the clarity benefit.

Full CQRS with separate stores earns its keep when the read load or the read shapes measurably cannot be served from the write database, or when the read models need a store the write side should not use. It is not a prerequisite for microservices, not required by event-driven architecture, and not made necessary by event sourcing — though event sourcing makes it nearly unavoidable, because an event log cannot be queried directly and needs projections to be readable. Adopt it because a query is slow and cannot be indexed into shape, not because a diagram looked cleaner with two boxes.