Issues, Special Considerations, and Performance Implications

CQRS is not free: the moment you split one model into a write side (commands that mutate state and emit events) and a read side (denormalized views rebuilt by projectors that consume those events), you inherit an asynchronous gap between "the write committed" and "every read reflects it" — and because the two sides live in different stores, you also lose the single ACID transaction that CRUD gave you for free. Everything below is a consequence of those two facts.

The mechanism the analogies skipped: how the read model actually gets updated

In a real CQRS deployment the read model is not updated by the same code path that handles the command. The command handler writes to the authoritative write store and emits a domain event (e.g. OrderPlaced); that event is published to a log or broker (Kafka, a transactional outbox, an event store); a separate projector consumes the event and upserts into one or more read stores (a denormalized Postgres view, an Elasticsearch index, a Redis cache). The lag between commit and projection is the "stale read" window — it is a physical property of the pipeline, not a bug. Typical numbers on a healthy Kafka pipeline: single-digit to low-tens of milliseconds; under consumer lag or a rebuild, seconds to minutes.

Worked trace: a customer places an order, then immediately refreshes

E-commerce checkout. Write model owns orders (normalized); read model serves GET /orders from a denormalized order_summary table updated by a Kafka consumer. The client fires the query 20ms after the command returns 202 Accepted.

The user hit a 45ms hole and saw an empty list on a purchase they just made. Nothing failed; the pipeline is working exactly as designed. Mitigations, in order of cost: (1) after a command, have the UI optimistically render the known result instead of re-querying; (2) return the new entity's version/offset and let the read side read-your-writes by waiting for the projector to reach that offset; (3) route the immediately-following read to the write store; (4) accept it and set user expectations. Do not "fix" it by writing to the read store synchronously inside the command handler — that recouples the two sides and reintroduces the dual-write problem below.

The transaction problem, mechanically — and its real fix

The original page raised "what if one command in a multi-step transaction fails?" but stopped at the wall-painting analogy. The mechanism: across services (Order, Payment, Inventory) there is no distributed ACID transaction — you cannot ROLLBACK a payment that already captured money in another service's database. The standard answer is a saga: model the flow as a sequence of local transactions, each emitting an event, and for every step define a compensating transaction that semantically undoes it.

1. OrderCreated (Order svc, local commit)
2. PaymentCaptured (Payment svc, local commit)
3. ReserveInventory fails — out of stock
4. Saga fires compensations in reverse: RefundPayment, then CancelOrder. Note the order is not deleted — it moves to a CANCELLED state. Compensation is forward motion, not an erase.

This is why CQRS pushes you toward event sourcing and sagas: once the read model is event-driven, modeling the write side as events makes compensation and audit natural. The cost is that every operation now needs a designed inverse, and intermediate states (payment captured, order not yet confirmed) are briefly visible.

Pitfalls

• Dual-write with no outbox. Writing the DB and then publishing to Kafka as two separate operations: if the process dies between them, the write is committed but the event is lost, and the read model silently diverges forever. Fix: transactional outbox (write event to same DB txn, relay publishes) or a change-data-capture stream — never two independent writes.
• Non-idempotent projectors. At-least-once delivery means the projector will occasionally see the same event twice. If projection does balance += amount, a redelivery double-counts. Fix: idempotent upserts keyed by event id / offset, or track last-applied offset per aggregate.
• Unbounded stale window under lag. Your 45ms window becomes 90 seconds when a consumer falls behind or during a full projection rebuild. If any business rule assumes fresh reads (e.g. "don't let them order the same seat twice"), enforce that invariant on the write side, never by querying the read model.
• Debugging across the async seam. A wrong number in a report may originate three services and one replay ago. Without a correlation/causation id threaded through every event, you cannot reconstruct the chain. Instrument it from day one; add it retroactively and you'll be grep-ing timestamps.
• Schema drift on rebuild. Read models are disposable and often rebuilt from the log. If old events don't deserialize into the new projector code, the rebuild stalls. Version your events and keep upcasters.

When to use CQRS — and when not to

Reach for it when concrete signals line up: a highly skewed read:write ratio (say 100:1) where you want to scale and cache reads independently; queries that need a shape the write schema can't serve cheaply (denormalized dashboards, full-text search, graph-like joins); a collaborative/high-contention domain where separating writes reduces lock pressure; or a domain that already benefits from event sourcing and audit.

Prefer simpler tools when those signals are absent:

• vs. a single shared CRUD model: CQRS gains independent scaling and query-optimized shapes; it costs two models to keep in sync, an eventual-consistency window, and real operational surface (broker, projectors, replay). Choose the shared model when reads and writes have the same shape and load — most CRUD apps.
• vs. read replicas of the same schema: replicas scale reads with almost no code and still give you the identical (normalized) schema — but they can't give you a different shape (no search index, no precomputed aggregates), and they carry their own replication lag. Choose replicas when you only need read throughput; choose CQRS when you need read throughput and a different model.
• vs. database materialized views: a materialized view is CQRS-lite inside one database — cheap, transactional-ish refresh, no broker. Choose it when the read model can live in the same DB and staleness of a periodic refresh is acceptable; graduate to full CQRS when the read side must be a different store or scale separately.

Rule of thumb: add CQRS to the specific bounded context that has the skew or the shape mismatch — never blanket the whole system. Most services should stay CRUD.

Takeaways

• The stale read is a physical property of an event-driven projection pipeline (commit → publish → consume → upsert), not a defect — measure the window and design reads-your-writes only where the UX demands it.
• You trade one ACID transaction for sagas + compensating transactions; every write step needs a designed inverse, and intermediate states become observable.
• Correctness across the async seam rests on three disciplines: transactional outbox (no lost events), idempotent projectors (no double-apply), and correlation ids (debuggability).
• Apply CQRS to the one context with a read/write skew or shape mismatch; a shared CRUD model, read replicas, or materialized views win everywhere else.

Sources: Chris Richardson, Microservices Patterns (Manning) — CQRS, Saga, and Transactional Outbox chapters; Martin Fowler, "CQRS" and "Event Sourcing" (martinfowler.com); Greg Young's original CQRS/event-sourcing talks; Microsoft Azure Architecture Center CQRS & Materialized View pattern guides; Confluent documentation on Kafka consumer lag and exactly-once/idempotent processing. Re-authored/Deepened for this guide.