TTL Jitter
TTL jitter randomizes expiration times by a fraction of the base TTL so thousands of keys do not expire in the same second, preventing synchronized expiry stampedes.
Definition
TTL jitter adds a random offset — commonly 10 to 30 percent of the base TTL — to each cache entry on write. Without jitter, keys written together during a warm-up or deploy expire together, producing synchronized misses and origin load spikes. With jitter, expirations smear across the TTL window.
Context and scope
Applied on CDN and application caches at write time. Pairs with request coalescing and stale-while-revalidate as complementary stampede defenses.
Common misconceptions
- Jitter solves single hot key stampedes — it de-synchronizes many keys; one hot key still needs coalescing or SWR
- Jitter increases average staleness — the expected staleness is the TTL itself; jitter only redistributes expiry timing around it
- Client-side cache headers cannot use jitter — dynamic responses can compute randomized Cache-Control max-age per request
Anti-patterns
- Seeding a cache with fixed TTLs after deploy and watching the whole cohort expire at once
- Applying jitter at read time instead of write time and serving unjittered entries already stored
- Using huge jitter ranges that make expiry behavior unpredictable in capacity planning
Related concepts
Related examples
Authoritative source
What it is
Caches are filled in bursts — deploys, warmups, traffic spikes. A fixed TTL turns the burst into an expiry burst: the same thousand keys expire at the same second, all miss together, and the origin sees a wave it created itself.
How it works
Each write computes TTL times (1 plus uniform random fraction), capping the multiplier. Expirations then spread roughly uniformly across the window. Jitter compounds: layered caches each applying jitter prevent aligned expiry cascades down the stack.
When to use it
Any cache written in batches: warm-up loops, CDN refreshes after deploy, application caches filled by scheduled jobs. Keep jitter proportional — enough to smear, little enough to reason about capacity.
Pitfalls
Jitter must happen at write time in the writer process; retrofitting read-side only affects new entries. Very short TTLs gain little from jitter — the stampede defense for them is coalescing. Document the jitter range, or future capacity models will mispredict expiry distributions.