CQRS Pattern

The orders service serves two very different clients. The checkout API needs to validate an order, apply inventory rules, and write it — a handful of rows, normalized, transactional, latency-critical. The operations dashboard needs 'all open orders for region West with customer name, last event, and SLA countdown, filterable and sortable' — a shape nobody normalized, served to hundreds of internal users. One table tries to do both: the dashboard's joins drag the checkout writes, and every new dashboard column becomes a migration on the transactional path. Command Query Responsibility Segregation is the recognition that these are two models with two responsibilities, so build two.

WRITE side (commands):                 READ side (queries):
  validate invariants                    shaped exactly for one screen
  single aggregate per transaction       denormalized joins, precomputed fields
  normalized schema                      schema owned by the reader's needs
  transactional, linearizable-ish        possibly stale, cacheable, wide
        │                                        ▲
        └── domain events / change stream ───────┘   (the projection feeds the read model)

The insight underneath: a model optimized for correct state transitions and a model optimized for fast reads have contradictory design pressures. Normalization prevents update anomalies (write-side concern); denormalization prevents expensive joins (read-side concern). Constraints and cascades protect invariants (write-side); flattened fields and materialized aggregates serve screens (read-side). Trying to satisfy both in one schema produces the compromise nobody likes — a 20-column table with three indexes that is mediocre at both jobs.

The command side's rules, worth stating in an interview: commands are intent (PlaceOrder, CancelOrder), validated against the aggregate's invariants before anything is persisted; the write model is the system of record, and exactly one service owns writes to it (the one-writer-per-fact rule from Polyglot Persistence returns here). After committing, the service publishes what happened (events via an outbox), and the read side builds its own views.

The read side's freedom is the payoff: the projection can hold a customer_name column joined in from another context, an sla_status computed at ingest, and a JSON blob of recent events — because nothing ever writes through the read model, there is no update anomaly to prevent and no migration to coordinate with the transactional path. It can also be rebuilt from scratch: a projection is a function of the event stream, so a bug fix is 'stop projection, deploy new logic, truncate, replay' — version control for data views.

What CQRS is not, since interviews probe this: it is not a database per se (it can be two tables in one Postgres), it does not require event sourcing (events are the most common feed, but CDC or explicit read-model updates work), and it is not microservices (one service can contain both sides). The pattern is specifically separating the responsibility of the model that mutates state from the model that answers reads — and the moment you say that, the follow-up question is about the costs, which are real and covered later in this topic. One more property is worth internalizing: the split is per bounded context, not per company. Applying CQRS to a simple CRUD service while its neighbors stay single-model is normal; forcing one global pattern across every service is how teams drown in ceremony they cannot cash out.

The read model is a table like any other, but with one property that changes everything about how you operate it: it is derived state. Everything in orders_dashboard can be reconstructed from the system of record — which means migrations become replays, bugs become rebuilds, and 'we added a column wrong' becomes an afternoon instead of an incident. Treat the projection as a function: view = f(events), deterministic and idempotent, and the operational playbook writes itself.

A concrete projection, fed by CDC or domain events:

-- projection: orders_open_dashboard (the ONLY thing the dashboard queries)
-- fed by consumer applying OrderPlaced / OrderShipped / SlaBreached events
INSERT INTO orders_open_dashboard
  (order_id, customer_name, region, sla_status, last_event_at, total)
VALUES (...)
ON CONFLICT (order_id) DO UPDATE SET ...;   -- idempotent upsert, safe on redelivery

The design rules that keep projections honest:

• Idempotent application. Every event carries an id; the projection records the last-applied position per stream/table and skips or upserts on replay. Redelivery then has no effect — this is the idempotent-consumer discipline applied to your own view (Event-Driven Architecture Patterns).
• Ordered per key, tolerated-out-of-order globally. Projections process a key's stream in order (partition by entity id) and version-guard transitions (WHERE last_version < :v) so a late event cannot regress a row.
• Freshness is declared, not hoped. The projection lag (newest event vs newest applied) is a first-class SLO: 'dashboard is at most 2 s behind' is an engineering statement with an alarm on it, not a disclaimer.
• Rebuild is a supported operation. Keep the bootstrap path exercised: rebuild into a shadow table on a schedule or in CI, compare a sample, swap. A projection you cannot rebuild is not derived state — it is an undocumented second database.
• Backfill on new consumers. Adding a column means replaying history or re-reading the system of record — plan it with the retention window in mind (log retention caps how far back you can rebuild; beyond that, snapshot + replay the tail).

The most valuable property in incidents: the read model can be wrong without the business being wrong. A dashboard showing a slightly stale total is a product annoyance; the ledger being wrong is an incident. Because the two are physically separate, you can degrade, rebuild, and pause one while the other keeps its guarantees — which is also why read projections are allowed to be eventually consistent, cached, and aggressively denormalized.

This structure also answers the classic scale question with real mechanics: reads scale by adding projection instances and read replicas with no impact on the write path; writes scale vertically or by partitioning the write model by aggregate. The two sides can fail independently — a dashboard rebuild storm cannot corrupt orders, and a checkout burst cannot make the dashboard worse than its declared lag. That independence is the same shape as Transactional vs Analytical Workloads, generalized from 'analytics vs serving' to 'every read view vs the write model'. The final chapter prices the pattern honestly, including when not to use it.

CQRS has a reputation for being over-engineered, and the reputation is deserved when teams adopt it for a CRUD app. The honest cost list, so you can price it before adopting:

The failure modes to name in design review: projections that silently stop (consumer healthy, lag growing — alarm on lag age, not just consumer liveness); non-idempotent projections that double-count on redelivery (the classic revenue bug); hidden second sources of truth where someone writes to the projection directly and it drifts; and event schemas so coupled to the write model that refactors break every consumer (the contract problem Schema Evolution and Compatibility exists to solve).

The decision rule, stated as an interview answer: CQRS pays when read and write shapes diverge significantly or scale independently; it is a tax when they do not. Concretely, adopt it when at least one is true — reads are far heavier than writes or need a different shape (dashboards, search-backed views); the domain has complex aggregates whose write model does not map to screens (logistics, insurance); or multiple read views over one write model are proliferating (three screens, four APIs). Skip it for straightforward CRUD where one normalized table plus indexes meets every requirement; the incremental middle ground — a materialized view, a read replica with rollups, a cached endpoint — delivers most of the benefit with none of the split.

A useful framing for the design doc: CQRS is the pattern that makes the read side a first-class, rebuildable artifact. Once you accept that framing, the surrounding decisions follow: the write model stays small and invariant-focused; projections are functions of a durable log; freshness is an SLO; and nothing writes to a view. Teams that adopt the split while keeping the discipline (idempotent projections, declared lag, rebuild drills) get the benefits teams complain about not having — and the ones that adopt the brand without the discipline get a CRUD app with extra steps. A useful rehearsal for the design review: ask 'what happens the day after a projection bug ships?' If the answer is 'we hand-edit rows', the team has adopted the split without the rebuild discipline, and the read model has quietly become a second source of truth. Next, the pattern's natural companion: what happens when the write model itself is an append-only log of facts — Event Sourcing.