In a Redis cache-aside setup, a slow read that missed can write its already-outdated value into the cache after a concurrent update has invalidated that key. How do you keep the stale value out, and where does SET with the NX flag help?

## The exact interleaving Write the timeline out; the bug is only visible in the ordering. ``` T1 Reader GET product:v1:915 -> nil (miss) T2 Reader SELECT ... WHERE id=915 -> price=10 (slow: GC pause, slow query, network) T3 Writer UPDATE ... price=20; COMMIT T4 Writer UNLINK product:v1:915 -> key absent (it was already absent) T5 Reader SET product:v1:915 price=10 EX 600 ``` After T5, Redis holds price=10 with a full 600-second TTL, and the database holds 20. No further event will correct it. This is *not* fixed by choosing write-then-invalidate ordering — write-then-invalidate is still the right order, and this residual race is what remains after you have chosen it. The window is the gap between the reader's database read completing and its cache write landing (T2→T5). Usually microseconds to a few milliseconds; occasionally a full GC pause or a retried connection makes it hundreds of milliseconds. Because it needs an unlucky interleaving with a write to the same key, it is rare — which is exactly why it survives testing and shows up as an unreproducible "the page showed the old price" ticket. ## Mitigation 1: bounded staleness (short TTL) The cheapest correct answer. If entries live 30-60 seconds rather than an hour, a lost race self-heals quickly. Many caches genuinely need nothing more, and saying so in an interview is a sign of judgment rather than of ignorance — provided you can also describe the stronger options and when they are warranted. ## Mitigation 2: delayed double delete After committing and deleting, schedule a **second** delete some hundreds of milliseconds later (a delay queue, a timer, a small worker). Any in-flight reader that was going to write a stale value has done so by then, and the second delete removes it. The next reader loads fresh. Properties: simple, no coordination, works regardless of value shape. Costs: you need somewhere reliable to run the delayed action (a crashed process silently drops it), it produces one extra miss, and the delay is a guess — too short and you miss slow readers, too long and you throw away useful entries. It is a probability reducer, not a proof. ## Mitigation 3: SET ... NX on repopulation `SET key value EX ttl NX` writes only if the key does **not** exist. Applied to the cache-aside fill path, it changes the reader's role from "author" to "filler of an empty slot". What that buys: - A reader can never overwrite a value a **writer** put there (if your write path populates rather than only deletes). - A slow reader can never overwrite a **fresher reader's** fill. Between two concurrent readers, the first to arrive wins and the late, older one is rejected — which is exactly the direction you want. What it does **not** buy: in the delete-only invalidation flow above, the key is genuinely absent at T5, so NX succeeds and the stale value still lands. NX is a necessary but insufficient guard; it removes clobbering, not the empty-slot fill. It composes well with the other techniques, and it costs nothing — the same single command with one more flag. Note that `SET` returns nil when NX rejects the write, so the client can observe and count rejections. Be careful not to confuse this use of NX with the *lock* use of NX for stampede control; here NX is guarding the value, not serializing the loaders. ## Mitigation 4: versioned compare-and-set write-back The robust fix: carry a monotonic version with the value — a row version column, an updated-at timestamp with sufficient resolution, or a transaction id. Store it inside the payload or in a companion field, and make the write-back conditional: install the new value only if its version is greater than the one currently cached (or if nothing is cached). Redis has no built-in conditional-on-content SET, so you implement it as either a tiny Lua script (read current, compare versions, set or skip — atomic because scripts run to completion on the server) or a `WATCH key` / `MULTI` / `EXEC` optimistic sequence where EXEC aborts if the key changed. A hash with a `ver` field plus a script is the common shape. This converts the write-back from last-writer-wins to highest-version-wins, which closes the race properly. The costs are real: a script or transaction on every fill, a version source you must trust to be monotonic (clock-derived timestamps across machines are not), and more code in a hot path. ## Choosing Ask what a stale value costs for the length of a TTL. A product description: short TTL is fine. A price, an entitlement, a feature flag, a balance: use versioned write-back, or do not cache the field at all and read it from the database. A middle tier — user profile, catalog metadata — is well served by write-then-invalidate + short TTL + NX fills + a delayed second delete. And whichever you choose, **instrument it**: an endpoint or job that samples cached values against the database and reports disagreement rate turns an invisible race into a number you can act on.