Once a Redis key's TTL elapses, no client can read its value any more — GET returns nil. Given that, how do you serve a slightly stale cached value to most callers while exactly one worker recomputes the fresh one, and how do you decide how much staleness to allow?

## The constraint A Redis TTL is a hard visibility boundary: once it elapses, the key is unreadable — `GET` returns nil, `EXISTS` returns 0, and there is no way to ask Redis for "the value that just expired". There is no built-in notion of "expired but still readable", no HTTP-style `stale-while-revalidate` directive that Redis honours on your behalf. (How Redis actually reclaims the memory behind an expired key is a separate concern and does not change what a client can observe.) So if you want stale-serving, you must build it out of a TTL you control plus metadata you store. ## Physical versus logical expiry The technique is to decouple two different questions: - **Physical expiry** — when Redis stops returning the key. This is the memory-management decision. Set it to `freshness_window + grace`. - **Logical expiry** — when the application considers the value stale. Stored *inside* the payload as an absolute timestamp. Because physical > logical, there is a grace window during which `GET` still returns the value while the application knows it is past due. That window is where the refresh happens, and it is why nobody ever has to block. Read path: 1. `GET product:42`. 2. Miss (grace exhausted, or never cached) → this really is a miss: take the lock, recompute, and either wait or degrade. Rare if the grace window is sized right. 3. Hit and `now < fresh_until` → return it. Done. 4. Hit and `now >= fresh_until` → attempt `SET lock:product:42 <token> NX PX 5000`. - Won: recompute, write a new payload with a new `fresh_until` and a new physical TTL, release the lock with a token-checking Lua script, return the fresh value (or return stale immediately and rebuild in the background — see below). - Lost: **return the stale value immediately**. No sleeping, no polling, no thread parked. ## The two-key variant If you cannot change the payload format, use a sentinel: - `v:product:42` — the value, TTL = freshness + grace (or no TTL at all, with explicit deletion). - `fresh:product:42` — a tiny marker with TTL = the freshness window. `EXISTS fresh:product:42` (or an `MGET` of both keys in one round trip) answers "is it fresh?". Absence means "stale, someone should refresh". Same semantics, no serialization change, one extra key per entry. In cluster mode give both keys a shared hash tag (`v:{product:42}`, `fresh:{product:42}`) so you can `MGET` them together. ## Sync versus async refresh The lock winner has two options: - **Refresh inline**: it recomputes and returns the fresh value, paying the latency. Fine when recompute is fast and you would like *someone* to see fresh data promptly. - **Refresh in the background**: it returns the stale value like everyone else and hands the rebuild to a worker or task. Now *no* request ever pays recompute latency, at the cost of needing a background execution path with its own error handling and concurrency limit. For latency-sensitive services this is the better default. ## Choosing the grace window Grace must cover: worst-case recompute latency, plus at least one retry after a failed recompute, plus scheduling delay if refreshes are asynchronous. Too short and the value becomes unreadable mid-refresh, dropping you into the real miss path — the situation you built this to avoid. Too long and stale data lives on after a refresh loop has quietly been broken for hours. ## Choosing the staleness budget This is a product decision, not an engineering one, and it should be made per data class: - **Seconds or less**: prices, inventory counts, anything a user is about to transact on, security decisions. - **Tens of seconds**: dashboards, counts, feeds, search facets. - **Minutes**: recommendations, related-items, trending lists, expensive aggregates. - **Deploy-scoped**: compiled configuration, static reference data. Write the chosen numbers down alongside the cache, because the next person will otherwise "tidy" them. And remember that staleness composes: if an in-process cache also sits in front, the windows add. ## Stale as an availability feature — with a hard cap Once you can serve stale, a failing source of truth stops being an outage: the cache absorbs it. That is genuinely valuable and worth designing for — the refresh fails, the stale value is returned, and users see slightly old data instead of errors. The danger is serving stale *forever*. Add a second, absolute bound — "never serve data older than X" — after which you fail loudly or degrade explicitly. Otherwise a broken refresh path is invisible until someone notices the numbers stopped moving last Tuesday. Instrument it: export the age of served values, alert when p99 age exceeds the freshness window, and count refresh failures separately from cache misses. ## Interaction with eviction A long physical TTL is a request, not a guarantee. Under `maxmemory` with an `allkeys-*` policy Redis may evict your stale copy regardless of remaining TTL, and a restart without persistence loses everything. Stale-serving is therefore a best-effort optimisation layered on top of a miss path that must still be correct — bounded recompute concurrency and a degradation response remain mandatory. ## Why this is usually the right default Compared with the alternatives: a bare mutex forces losers to wait or fail; probabilistic early refresh needs metadata plus enough traffic and does nothing on a cold cache; async background refresh of a fixed key list does not generalise. Stale-serving degrades gracefully in every direction — it turns expiry from an event into a soft transition, keeps latency flat, and converts source-of-truth outages into freshness incidents. Its price is that you must decide, explicitly, how old is too old.