A user submits a form that appends an event to the log, then the client immediately navigates to a page that reads from a projection built off that log - and the change is missing. What is actually happening here, and what are the common ways to handle it?

## What is actually happening **Read-your-writes** is the specific consistency guarantee people expect by default - 'after I successfully save something, if I immediately look at it, I should see my own change' - and it is exactly what asynchronous, log-derived projections do not give you for free. The mechanism producing the gap is straightforward: a write appends an event to the log and returns success as soon as that append is durable; the projection, however, learns about that event only when its subscriber next reads and processes it, which happens on its own schedule - milliseconds later under light load, longer under a backlog. Between those two moments, any read against the projection reflects the state before the new event, even though the write has already succeeded from the client's point of view. This isn't a bug; it's the direct cost of decoupling reads from writes, which is the entire reason projections are fast and scalable in the first place. ## Why the trade-off is accepted The reason this trade-off is accepted is that strict, always-consistent reads would mean either: - not decoupling the read model from the write model at all (losing the query-shape and scaling benefits), or - synchronously updating every projection inside the same transaction as the write (which reintroduces tight coupling and doesn't scale to multiple projections or multiple read replicas). Accepting a small inconsistency window in exchange for a decoupled, horizontally scalable, purpose-built read side is the deliberate bet event sourcing with projections makes. ## The mitigations Several concrete techniques mitigate the read-your-writes problem without abandoning the async projection architecture. - One is **version or position tracking**: the write endpoint returns the event's resulting stream position (or a monotonic version number) to the client, and the subsequent read either polls the projection until its checkpoint is at or past that position, or the server blocks the read request momentarily until the projection catches up, bounded by a timeout to avoid hanging forever under heavy lag. - A second is **optimistic UI**: the client renders the expected post-write state immediately from the data it just submitted, without waiting on the projection at all, and reconciles silently if the eventual server read differs - this is the most common approach in consumer-facing apps because it hides the lag entirely from the user's perceived experience. - A third, used sparingly, is **bypassing the projection** for the specific read that needs strong consistency: reading the aggregate directly from the write-side event stream (replaying just that one aggregate's events, which is cheap because a single aggregate's history is small) instead of the shared projection, trading a bit of extra latency on that one call for correctness. - A fourth is **session or sticky consistency**: routing a given user's subsequent reads to the same projection replica they just wrote through, common when multiple projection replicas exist behind a load balancer and different replicas may lag by different amounts. ## Failure modes Failure modes in production tend to cluster around forgetting this gap exists rather than not knowing the mitigations. 1. The most common is a UI that shows **a jarring flicker** - the item is missing for a moment then pops in - because no mitigation was applied and the projection lag happened to be visible under load, which erodes user trust even though nothing was actually lost. 2. A second is choosing a **naive fixed 'sleep 200ms before redirecting' hack**, which works in testing under low load but breaks under production traffic spikes when actual lag exceeds the hardcoded delay, producing intermittent, hard-to-reproduce bug reports. 3. A third, more serious failure is silently reading from **a stale replica** in a way that looks like data loss - support tickets say 'my order disappeared' when actually a replica behind a load balancer just hasn't caught up, and without version tracking or sticky routing, it's hard to distinguish real data loss from ordinary catch-up lag during incident triage. 4. A fourth is **over-correcting**: making every read block on projection catch-up 'just to be safe,' which quietly reintroduces the very latency and scaling costs projections exist to avoid. ## A real-world pattern A concrete, widely used real-world pattern: many e-commerce checkout flows use exactly the optimistic-UI approach - after a successful 'place order' call, the confirmation page renders directly from the data the client just submitted rather than re-querying the orders read model, while the `orders_view` projection catches up in the background for the order-history page the user will see later, by which time the lag is imperceptible.