In a CQRS system where the write side uses Event Sourcing, a user submits a command that changes data, and the client immediately re-queries a read model to display the result — but the change is missing or shows stale data. Why does this happen structurally, and what are the common ways teams handle it?

## Why the stale read is structural This is usually called the **read-your-own-writes** problem, and in a CQRS+Event-Sourcing system it isn't a bug to be fixed so much as a direct, unavoidable consequence of how the two sides are wired together. The command path and the query path are, by design, two separate pipelines with no shared transaction between them. - When a command handler processes a request, its entire job — reconstituting the aggregate, running the business logic, and appending the resulting event(s) to the event store — ends the instant that append durably succeeds. Nothing in that call path waits for, or even knows about, any read model. - Separately, and asynchronously, a projector process is subscribed to the event stream; at some point after the append, it notices the new event, applies it, and updates the read store the UI actually queries. The gap between 'event durably appended' and 'projection updated' is real wall-clock time — usually milliseconds under healthy conditions, but it can stretch to seconds or longer under load, projector lag, or an outage — and any read that lands inside that gap sees the old state. ## How this differs from replica lag This differs meaningfully from the read-your-own-writes problem in, say, a simple primary/replica relational database, where the same underlying failure mode (replication lag) exists but is often narrower and more bounded, because the primary and replica run near-identical logic over near-identical data. In CQRS+ES, the read model can be an entirely different shape from the event stream — sometimes involving nontrivial aggregation, joins across multiple aggregate streams, or external lookups — so the lag isn't just network replication delay, it's real processing time, and it can vary a lot depending on what the specific projection has to do with that event. ## The three mitigations 1. The most direct mitigation is **version-aware polling**: the command handler's response includes the stream version (or a global sequence position) of the event it just appended, and the client — or, better, a thin layer in the API — then either polls the read model's own tracked 'last processed version' until it's caught up to at least that number, or the query endpoint itself blocks briefly until the projection has caught up before returning. This gives a precise, per-request consistency guarantee without making every read wait on every write system-wide — only the specific request that just wrote has to wait for its own change to land. 2. A second, cheaper mitigation is **optimistic UI update**: the client doesn't re-query the read model at all after a successful command; it locally merges the change it already knows it just made (from the command's own request/response) into what it displays, and lets the background projection catch up invisibly for everyone else. This sidesteps the lag entirely for the acting user's immediate experience, at the cost of the client needing to know how to render its own optimistic state. 3. A third approach, used when the UI genuinely needs to read the freshest possible state right after writing, is to **route that specific follow-up read to a strongly consistent source** instead of the eventually-consistent projection — reconstituting the aggregate directly (the same path the command handler used) or reading from a synchronously-updated cache keyed by aggregate ID — accepting the cost of bypassing the purpose-built read model for that one call. ## Failure modes that compound it The failure modes that show up in production tend to compound this problem rather than being separate from it. - **Projector lag under load** is the big one: if event volume spikes (a batch import, a traffic surge) faster than a projection can keep up, the read-your-writes window stretches from milliseconds to potentially minutes, and a mitigation designed around 'usually fast enough' polling can start timing out or degrading the UX badly right when the system is under the most stress. - **A second failure mode is inconsistent expectations across a team**: without an explicit, agreed-upon consistency contract for a given read model, some engineers write client code assuming synchronous consistency (breaking under normal async lag) while others over-defensively poll everywhere (adding needless latency to reads that never needed it), and the inconsistency itself becomes a source of subtle bugs and support tickets. ## How checkout screens sidestep the lag A concrete, well-known real-world instance of this pattern: e-commerce checkout flows commonly show an 'order confirmed' screen driven entirely from the command's own response payload (order ID, items, total) rather than by immediately re-querying an 'order history' read model, precisely so the confirmation page can render instantly and correctly regardless of how far behind the order-history projection happens to be at that moment — the read model catches up in the background, and by the time the user navigates to 'my orders,' it almost always has.