A pushed update for a key arrives while a request for that same key is still in flight — which write wins?

## Why the collision exists at all A cache entry has two writers. One is the request path: a component or loader asks for a key, and some time later a response arrives. The other is the bridge: an event for that key arrives whenever the server decides. Nothing coordinates them. The window is wide in practice — a slow request on a mobile network is hundreds of milliseconds to seconds, and the change that triggered the event may have happened inside that window. ## What a response actually means This is the point candidates miss. **A response is a snapshot of server state at the moment the server handled the request, not at the moment the client receives it.** So the sequence 1. client starts a read of `K`; 2. server reads `K` and starts serialising the old value; 3. someone changes `K`; the server emits an event; 4. the event reaches the client and the bridge writes the *new* value; 5. the response reaches the client carrying the *old* value ends with the cache holding the old value, despite every step behaving correctly. Last-write-wins on arrival is simply the wrong ordering function. ## Three resolutions | Approach | How it decides | Requires | Weakness | |---|---|---|---| | **Compare markers** | reject any write whose revision or server timestamp is not newer than the entry's | a monotonic marker on both responses and events | needs a server contract; clock-based markers are fragile across nodes | | **Refetch after the collision** | note that a push landed during the in-flight read, then refetch once it settles | nothing from the server | one extra round trip, and a brief window showing the older value | | **Prefer the event and drop the response** | assume the event is newer because it arrived later | nothing | wrong whenever the event described a change the response already includes, and it discards a full payload for a partial one | A fourth arrangement is worth knowing: **let the request own the entry while it is in flight**, meaning pushed events for that key are queued rather than applied, and replayed onto the entry after the response lands. It preserves order relative to the response but only if you are sure the response predates every queued event, which is exactly the thing you cannot know without a marker. ## Making the writes comparable The durable fix is a **revision** the server owns and stamps on both the resource and its events — a counter that only increases per record, or a version the write path already maintains for concurrency control. With one: - every write to an entry carries a marker; - the cache compares before applying and drops the older write; - out-of-order delivery of two events becomes safe too, not just push-versus-response. Timestamps are the common substitute and are weaker: they only order correctly if one clock produced them. A counter per record, or per stream, is more robust. ## Without a marker, prefer a refetch When you cannot get a marker, the honest position is that the cache **cannot tell which value is newer**, so it should not pretend. Mark the entry as contended, let the in-flight request settle, then invalidate and read again. It costs a round trip in an uncommon case, and it converges on the server's answer, which is the only one the user can check against. Do not paper over it with a delay before applying events — a fixed delay is an unmeasured guess and hides the race instead of resolving it. ## Where this bites in the product - **A detail screen opened right after an action.** The read starts, the action's own event arrives first, then the stale response paints over it, and the user sees their change revert on screen. - **A refetch triggered by the reconnect itself.** The catch-up read and a flood of resumed events race by construction; this is the single most likely place to hit the bug. - **Paged lists.** A response for page 2 that predates an insertion, merged next to pushed rows, produces duplicates or gaps that look like a pagination bug rather than a race. ## What good looks like in an answer Say that arrival order is not age order; name the marker-comparison fix and what it demands of the server; name the refetch fallback and its cost; and be explicit that discarding one side by rule is a guess. If you have to pick a default with no server changes available, the defensible one is *apply the event, then refetch once the request settles* — the user sees the newer value immediately and the cache converges on truth shortly after.