Redis key-value store: missing stale‑while‑revalidate configuration option

Answer the question first

Redis has no redis.conf directive that automatically serves a stale value for an expired key while a background refresh runs. The expiration contract is hard‑coded: once the TTL reaches zero, the key is considered non‑existent and GET returns nil. The only configuration that delays the physical removal of the key is lazyfree-lazy‑expire, which only affects when the memory is reclaimed, not what a client receives.

Why a native stale‑while‑revalidate cannot exist in the core

• TTL is a hard invalidation point; Redis does not keep a “stale” state for expired keys.
• Serving stale data would require new metadata per key, a background refresh coordinator, and stampede protection logic—all of which are missing from the core engine.
• Adding such a feature would interfere with eviction policies (LRU, maxmemory), keyspace notifications, and the semantics of EXPIRE, TTL, and PERSIST.

How to implement stale‑while‑revalidate in practice

The most common patterns are:

1. Lua script with a “stale” flag
   

   -- Pseudo‑Lua
   local val = redis.call('GET', 'mykey')
   if val then
     return val
   end
   -- key is expired or missing
   -- trigger a background refresh via a separate process
   return nil
   

   In this pattern you keep a separate key (e.g., mykey:stale) that holds the last known value. The Lua script first checks mykey; if it’s missing, it falls back to mykey:stale and optionally kicks off a refresh.

2. Redis module
   

   Write a small module that exposes a command like SWRGET key. The module can maintain an internal “stale” flag and schedule a background refresh using PROTECTED callbacks. This keeps the logic inside Redis but requires compiling the module and managing its lifetime.

3. Application‑level stampede protection
   

   Use SET key value NX PX 300000 to lock refreshes. When a GET sees a nil, it attempts to acquire the lock; if it succeeds, it performs the refresh, otherwise it serves the stale copy.

Interaction with lazyfree‑lazy‑expire

Enabling lazyfree-lazy‑expire yes only defers the memory reclamation of the key after it has expired. The key is still considered absent to clients. Therefore, the stale‑while‑revalidate logic must store the stale copy in a separate key or in memory managed by a Lua script/module; lazyfree‑lazy‑expire does not help you serve stale data.

Effect on eviction and maxmemory

• Stale copies increase the effective memory footprint beyond the original TTL, so you may hit maxmemory sooner.
• If you keep two keys (original + stale), eviction will treat them as separate entries. LRU approximations will consider the stale copy’s last access time, potentially keeping it alive longer than intended.
• Keyspace notifications for expired events will fire only for the original key; the stale copy will remain until you delete it explicitly.

Suggested default stale window

There is no “one‑size‑fits‑all” value. A common practice is to set the stale window to a fraction of the original TTL (e.g., 10‑20%) or a fixed value like 30 s, depending on how frequently the background refresh can run and the acceptable staleness for your use case.

Next diagnostic step

To tailor this solution to your environment, please confirm the Redis version you are running:

redis-cli INFO server | grep redis_version

Older releases may not support the same Lua features or module APIs, and the behaviour of lazyfree‑lazy‑expire can vary between 6.x, 7.x, and 8.x.

Summary

Redis cannot be configured to return stale values for expired keys out of the box. Implementing stale‑while‑revalidate requires additional logic—Lua scripts, modules, or application‑level coordination—and will affect memory usage and eviction behaviour. Verify your Redis version, choose a stale window that matches your freshness requirements, and decide whether to keep a separate stale copy or handle the logic in Lua.