Cache stampede protection: leases, request coalescing, TTL jitter
Parent: Read Offload via Caching and Precomputed Views ($merge/$out, Computed Pattern) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Cache stampede protection: leases, request coalescing, TTL jitter. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Application guidance for read offload: coordinate the expensive refill per logical result, spread TTLs across results, and decide whether stale results are acceptable while refresh runs. These are cache-layer design inferences from the cited mechanisms; they do not establish a built-in MongoDB stampede guarantee. (medium confidence) [source]
How it works
- A cache-refill lease can combine authorization to populate a key with throttling of refill attempts. Facebook's design binds a token to the requested key, checks it on refill, and invalidates it when a delete arrives, preventing an obsolete fill from being accepted. (low confidence) [source]
- Refreshing every request inside a fixed early-refresh window can merely move the stampede earlier. Early refresh still needs a mechanism that limits concurrent origin work. (low confidence) [source]
Problems, failure modes and limitations
- A hot cache entry can cause concurrent backend recomputation when it expires. Longer recomputation leaves more time for duplicate misses, and the resulting load can slow recomputation further. (high confidence) [source]
- Probabilistic early refresh lets requests volunteer before expiry and avoids a shared lock-service round trip. It reduces stampede risk but permits multiple refreshes, or no refresh in a given interval; it cannot replace coordination when a strict single-refill guarantee is required. (high confidence) [source]
- Lock-based refresh needs a follower policy: callers can wait for regeneration or use a retained stale value when the application permits it. Without a usable value, callers need an explicit absence or failure path. (medium confidence) [source]
- Refresh locks require failure handling and a suitable expiry. If the owner fails, followers can remain blocked or receive stale data until recovery; contacting a shared lock service also adds latency and an availability dependency. (medium confidence) [source]
Facts and statements
- Go singleflight.Group.Do suppresses overlapping calls for the same key within that Group. Its shared in-memory Group is not a cross-machine lease service; separate application instances need coordination if one fleet-wide refresh is required. (high confidence) [source]
- Random TTL jitter spreads expiration times across keys and reduces synchronized backend refill load. It complements per-key coalescing: choosing a random expiry for one shared key does not itself serialize that key's concurrent misses. The latter conclusion follows from the mechanisms' different scopes. (medium confidence) [source]
- Facebook's 2013 implementation rate-limited lease-token issuance per key and told other callers to wait briefly. Treat this as a historical implementation example, not a universal lease-duration recommendation. (low confidence) [source]
- Non-leading requests need an explicit response policy: wait for regeneration, return an acceptable stale value, or handle the missing value. A failed lock holder can leave readers waiting or using stale data until the lock expires. (high confidence) [source]
- Lock TTL must accommodate regeneration time: if it expires while regeneration is still running, another caller can start duplicate work. Long lock lifetimes also delay recovery after a holder fails, so lease duration and waiter behavior need joint design. (medium confidence) [source]
- Per-key request coalescing allows one in-flight computation and shares its result with concurrent callers, reducing duplicate origin work within the coordinator's scope. (high confidence) [source]
- Facebook's 2013 memcache design issues a key-bound lease token on a miss and validates that token on cache fill. A delete invalidates the token, preventing an obsolete fill. Rate-limiting lease issuance also reduces simultaneous database fetches while other clients wait and retry. These are properties of that design, not guarantees of every Memcached deployment. (low confidence) [source]
- Probabilistic early refresh lets requests independently decide to regenerate before expiry, with refresh probability increasing near expiration. This avoids a shared lock but provides no deterministic guarantee of exactly one origin request. (medium confidence) [source]
Children
- Stale-while-revalidate freshness budgets (frontier)
- Cache refill admission control and bounded waiting (frontier)
- Probabilistic early expiration (frontier)
- Lease-token validation and stale cache fills (frontier)
- Stale-while-revalidate follower policies (frontier)
- Probabilistic early cache refresh (frontier)
Frontier under this node: Cache refill admission control and bounded waiting, Lease-token validation and stale cache fills, Probabilistic early cache refresh, Stale-while-revalidate follower policies, Stale-while-revalidate freshness budgets