Refresh Ahead

In refresh-ahead, the cache proactively refreshes entries before their TTL expires. The classic trigger is a TTL threshold: if a key has a 60-second TTL, the system refreshes it when only 5 seconds of life remain. The refresh happens in the background — a worker thread or scheduler re-fetches the value from the DB and overwrites the cache entry, resetting the TTL. Foreground reads continue to hit the (slightly older but still valid) cache entry; they never see a miss and they never wait for a DB fetch.

This is the strategy that solves the cache stampede for read-only hot keys. Recall that write-through eliminates the stampede for write-heavy hot keys — the writes keep the cache warm. But for read-only hot keys (a viral post nobody is editing, a leaderboard, a homepage), there are no writes to keep the cache warm, and the TTL will eventually fire. Refresh-ahead is the answer: refresh before expiry, never let the cache miss for hot keys.

The trick is identifying which keys are hot. Refreshing every key before expiry defeats the purpose — most keys are never read again, and refreshing them is pure waste. The two common approaches are: (a) refresh only keys that have been read at least N times in the last interval (popularity tracking), and (b) refresh only keys whose TTL is about to expire and that were read recently (lazy refresh). Both aim to refresh only the keys that, if expired, would cause a stampede.

Three ways to trigger the refresh.

The refresh-ahead scheduler can be triggered in three ways, with different trade-offs:

1. Time-based (TTL margin). Each key has a TTL; a background scheduler periodically scans for keys whose TTL is below the refresh threshold (e.g., 5 seconds remaining) and refreshes them. Simple, but scans every key — wasteful if most keys are cold.

2. Popularity-based. Track per-key read counts in a sliding window. Refresh only keys above a popularity threshold. This focuses refresh work on keys that actually cause stampedes, but the popularity tracking itself is a data structure you have to maintain (often a sorted set or a count-min sketch).

3. Read-triggered (lazy refresh). On a read, if the TTL is below the refresh threshold, return the cached value and trigger an async refresh. The current read still hits; the next read sees a fresh value. This is the cheapest to implement because it requires no background scheduler — refresh is piggybacked on real reads. The downside is that the first read after the threshold sees the slightly stale value (though not as stale as cache-aside).

Most production systems use (2) or (3). Variant (3) — sometimes called stale-while-revalidate at the cache level — is built into HTTP's Cache-Control: stale-while-revalidate and into CDN behaviors, and is the easiest to add to an existing cache-aside system.

The waste problem and the cold-key problem.

Refresh-ahead has two failure modes that pull in opposite directions:

• Over-refreshing: if you refresh every key before expiry, you spend DB load on keys that are never read again. A key that was hot an hour ago but is now cold still gets refreshed — pure waste. The cost scales with the size of the cache, not with the read traffic.
• Under-refreshing: if you only refresh popular keys, a key that suddenly becomes viral in the gap between refresh and expiry still stampedes. Refresh-ahead protects against steady-state hot keys, not against sudden spikes.

The standard mitigation for over-refreshing is to combine refresh-ahead with a popularity signal: only refresh keys that have been read at least N times in the last interval. This bounds the refresh work to the actual hot set. The standard mitigation for under-refreshing (sudden spikes) is to also have stampede protection on the read path — cache locking (single-flight) or probabilistic early expiration — so that even if a key slips through, the stampede is bounded to one DB fetch.

The deeper insight is that refresh-ahead optimizes for steady-state hot keys, not for spikes. If your access pattern is bursty — a key goes from 0 reads to 10,000 reads in a second — refresh-ahead will not help, because the key was not popular before the burst. For bursty traffic, you need stampede protection (single-flight) plus a short TTL, or pre-warming based on predictive signals.

When to use refresh-ahead:

• Hot, read-only keys with steady-state traffic. Leaderboards, trending lists, homepage feeds.
• Keys whose expiry causes stampedes you have observed in production. Don't add it preemptively — add it when you see the stampede.
• HTTP/CDN-cached responses. stale-while-revalidate is free; use it.
• When you can identify the hot set in advance. Pre-warming at scheduled times (e.g., refresh homepage every minute during peak hours).

When NOT to use refresh-ahead:

• When keys are rarely read twice. Refreshing them is pure waste — let them expire and let cache-aside re-populate on the rare read.
• When access patterns are bursty. Refresh-ahead protects steady-state, not spikes. Use single-flight instead.
• When the DB cannot handle the refresh load. Refresh-ahead adds background DB load proportional to the hot set size; if the DB is already at capacity, this hurts rather than helps.
• When freshness does not matter. If a 5-minute stale window is fine, cache-aside with TTL is simpler and equally effective.

Mental model. Think of Refresh Ahead as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Refresh Ahead mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose Refresh Ahead, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

A useful first-order model is cache_load = request_rate × (1 - hit_rate). If traffic is 20,000 req/s and the hit rate is 90%, roughly 2,000 req/s still reaches the origin before considering misses caused by expiration or eviction.