Refresh-Ahead Cache

Proactively re-fetch a cached value from the database shortly before its TTL expires, in the background, so a request never has to wait on a cache miss for a key that is still being actively read.

Passive TTL expiration means every cached key eventually goes cold, and the request that happens to arrive right after expiry pays the full database round- trip synchronously and, if the key is hot, can trigger a stampede of identical concurrent misses; refresh-ahead avoids paying this cost on the request path for keys that are still actively being read.

In passive TTL expiration (the safety net cache-aside relies on), a key sits in the cache until its TTL elapses, then disappears entirely; the next request for that key is a full miss and pays the database round-trip synchronously, in the request path. Refresh-ahead changes this by watching access recency and expiry time: when a cached key is still being read close to its expiry, a background process re-fetches the value from the database and rewrites the cache entry before the old one expires, so the key never actually goes cold while it remains hot.

Contrast with the two mechanisms it is most easily confused with: - Passive TTL expiration: the cache entry simply disappears at expiry; the next

reader pays the full miss cost synchronously. No background work happens.

- Read-through: population happens lazily, in the request path, on a miss — the

reader that causes the miss is the one who pays for it. Read-through's miss

coalescing prevents duplicate concurrent fetches, but it does not prevent the

fetch itself from happening synchronously to a request.

- Refresh-ahead: population happens proactively, out of the request path, before

the entry would otherwise expire. No reader pays a miss cost for a key that is

being kept warm this way, at the cost of running background refresh work for

keys whose next read may not actually happen.

Refresh-ahead is a stampede-avoidance technique in the same family as mutex locking and probabilistic early expiry, all of which exist because a cache key expiring under sustained read load is the single most common trigger for a cache stampede. Refresh-ahead avoids the stampede differently than mutex locking or probabilistic early expiry do: instead of controlling how concurrent requests behave *after* a miss happens, it tries to prevent the miss from happening at all for keys that are still being actively read. It does not eliminate stampede risk entirely: a key that is refreshed just as its refresh window opens, but then receives an unexpected burst of new concurrent readers before the refresh completes, can still stampede exactly as it would under passive TTL expiration. Refresh-ahead is a mitigation for the common case (steady access to a hot key), not a guarantee against every miss-under-load scenario.