# Cache stampede protection: leases, request coalescing, TTL jitter > Source-anchored research for Cache stampede protection: leases, request coalescing, TTL jitter. Run status: COMPLETED. Parent: [Read Offload via Caching and Precomputed Views ($merge/$out, Computed Pattern)](https://llms-explorer.com/tree/read-offload-via-caching-and-precomputed-views-merge-out-computed-pattern/) · 4 facets · 15 facts · page: https://llms-explorer.com/tree/cache-stampede-protection-leases-request-coalescing-ttl-jitter/ ## 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](https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf) ## 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](https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf) - 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](https://blog.cloudflare.com/sometimes-i-cache/) ## 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](https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf) - 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](https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf) - 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](https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf) - 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](https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf) ## 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](https://pkg.go.dev/golang.org/x/sync/singleflight) - 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](https://docs.aws.amazon.com/whitepapers/latest/database-caching-strategies-using-redis/cache-validity.html) - 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](https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf) - 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](https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf) - 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](https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf) - 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](https://pkg.go.dev/golang.org/x/sync/singleflight) - 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](https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf) - 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](https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf)