Cache eviction
Cache eviction is the removal of objects from a cache before their TTL expires, because the cache needs the space for content it considers more valuable. Every shared cache does it — a CDN PoP stores many tenants' content in finite storage, and something has to give. Eviction is the reason a 30-day TTL doesn't mean your object lives 30 days.
How caches decide what to drop
The textbook answer is LRU — least recently used goes first. Production systems use smarter variants (frequency-aware algorithms like LFU hybrids, size-aware policies that sacrifice one huge object to keep hundreds of small ones, admission policies that don't cache one-hit wonders at all). The common thread: rarely requested objects are always the first to go. Your homepage survives everywhere; page 47 of your archive doesn't.
What we measured
Eviction pressure varies enormously by location. Across 408,000 requests to 47 Cloudflare colos — same URLs, same TTLs, same schedule — steady-state miss rates ranged from 0.0% (Milan, Vienna, Amsterdam) to 9.4% (Larnaca) and 8.6% (Tokyo). Busy European colos with lots of storage near our origins held everything; remote or smaller locations kept forgetting. The far edge — where a refill also costs the longest origin round trip — is exactly where eviction bites hardest.
What you can do about it
- You can't configure it away: eviction policies are the CDN's, not yours. Longer TTLs don't help an object nobody requests.
- Keep objects "requested": regular warming passes reset the recency clock at every PoP, which is precisely what keeps long-tail URLs resident.
- Add cache layers: tiered caching and origin shields give evicted edge objects a cheaper refill source than the origin.
- Watch for it: repeated MISS at one location for a URL you know was cached there is eviction's signature — visible in a multi-location cache check.