A team is about to apply CQRS with an eventually-consistent read model to a feature that checks a user's account balance before authorizing a withdrawal. As the architect reviewing the design, what makes this a case where you'd push back and require strong (immediate) consistency instead, and what are the concrete ways to get it without abandoning CQRS entirely?

## The question that decides it The decision hinges on a single question: is this read purely informational, used only for display, or does it feed a subsequent decision that changes state? - **If a read result is used to decide whether to authorize a command** — 'read the balance, then decide whether to allow the withdrawal' — it sits squarely in the danger zone, because it compounds a classic **check-then-act** race with the added risk of the checked value being stale on top of merely being racy. - **A display-only read**, by contrast, being briefly wrong just means a number on screen is a few seconds out of date, which self-corrects and costs nothing real. ## Why the distinction exists This distinction exists because CQRS's core benefit — scaling reads independently of writes by decoupling them — necessarily reintroduces a staleness window as its price. Some domain invariants are strict and must never be violated: - financial balances - unique-username reservation - inventory oversell prevention - seat-booking uniqueness For these, the cost of a violation — real money lost, a double-booked seat, a compliance incident — vastly outweighs the read-scaling benefit for that one specific decision path, even though the same eventually-consistent read model remains perfectly appropriate for the other 95% of the application's reads. ## The concrete fixes The concrete fixes trade off differently. 1. **Routing the authorization read directly to the write-side database** (or a synchronously-replicated, strongly-consistent replica) defeats part of CQRS's scaling purpose for that one path — it couples read load back onto the write database and forfeits the fast denormalized store — but it's a narrow, deliberate, well-scoped exception, not an abandonment of CQRS elsewhere. 2. **Pushing the invariant fully into the write side** is architecturally the cleanest option: the write model's own command handler re-reads the current authoritative state and makes the decision atomically inside its own transaction, so it doesn't matter at all what a lagging read model displays to the user, because the read model is never consulted for the actual decision. This does mean duplicating some 'read' logic (checking sufficiency) inside the write model, which can feel redundant with what the read model already computes for display, but that redundancy is the point — the write side must never trust a value it didn't itself just read inside its own transaction. 3. **A quorum or leader read**, a narrower option some databases support directly, scoped to just this query, trading a small latency cost for a strong-consistency guarantee without rearchitecting anything. ## What getting it wrong looks like Getting this wrong produces a specific, well-known failure mode: two concurrent withdrawal requests both read a stale-but-locally-sufficient balance from the read model at nearly the same instant, both get authorized against that stale value, and the account goes negative — a textbook **time-of-check-to-time-of-use (TOCTOU)** race, made worse here because the 'check' itself was reading a value that could already be behind the true, currently-committed balance. A common but ultimately false fix is simply tightening the projector pipeline to reduce lag — making the read model catch up faster narrows the race window and reduces how often it's hit, but any nonzero lag, however small, still leaves the race mathematically possible; speed is a mitigation of frequency and severity, not a structural guarantee, and treating it as a fix creates a false sense of safety instead of actually closing the hole. The structural fix has to be moving the check into the write model's own atomic transaction, not making the async pipeline faster. ## Where it shows up This dual-speed resolution — fast, loosely-consistent reads for display; strict, authoritative checks inside write-side transactions for anything that authorizes a state change — is the standard guidance in CQRS literature, and shows up concretely in real systems: - banking core systems and payment processors enforce balance checks inside the ledger's own transaction rather than trusting any denormalized reporting view; - e-commerce checkout flows commonly re-validate stock inside the order-placement write transaction even though the 'in stock' indicator a shopper sees on the product page comes from a fast, potentially-stale read model. The principle generalizes well beyond this one example: any time a CQRS read feeds an authorization decision rather than merely rendering a screen, that specific read deserves scrutiny for whether it needs to be pulled out of the eventually-consistent path entirely.