Skip to main content
Cache Eviction & Stampedelesson 1 of 7 · 2 min read

Eviction Policies

Something has to leave

Your cache is full and a new entry arrives. Something has to go, and your eviction policy picks the victim.

Start with least recently used, which evicts whatever has gone longest without being touched. It bets that data touched recently gets touched again, and for most web work that bet pays: sessions, product pages, profiles.

Take it as your default, which it is nearly everywhere, for exactly that reason.

Know its one famous weakness: a scan. A batch job or a crawler reading a million cold keys once marches straight through and evicts your entire hot set to store data nobody will ask for twice.

Resist that by counting instead of timing. Least frequently used evicts the least popular entry, which protects stable favourites and adapts slowly when popularity shifts, because an old hit count takes time to fade.

Reach for it on skewed workloads, where a small set of keys takes most of your traffic.

Learn one implementation detail if you run Redis: both of those policies are approximations there. Tracking exact recency for millions of keys costs memory and time, so it samples a handful and evicts the best candidate among them. Close enough in practice and far cheaper.

Expiry is not eviction

Stop lumping expiry in with eviction, because they answer different questions. Eviction answers we are out of memory, what goes. Expiry answers this data is too old to trust.

Configure both. A memory limit with a policy so your cache degrades gracefully under pressure, and expiries so your staleness stays bounded.

Avoid the setting that refuses to evict anything, because a cache configured that way stops accepting writes when full. That surprises teams at the worst possible moment, usually during the traffic spike that is also filling the cache faster than usual.

the shape of it
New entryCache full8 GB of 40300 hot productskeep theseOvernight scanevict thesesomething leavesthe right victim
step 1 of 2
The eviction rule decides whether a nightly scan of the catalogue throws out the products people actually buy.

Worked example

Rafael runs a Redis cluster caching listing pages for a real estate site, allkeys-lru, hit rate a steady 94 percent. Every night at 2 am the data science team's crawler regenerates SEO snapshots by fetching 3 million listing URLs, most of them for listings nobody has viewed in months. Each fetch goes through the same cache-aside path, so the crawler's cold keys flood Redis and evict the hot set. At 6 am, when real traffic ramps, the hit rate starts at 58 percent and the database has its worst hour of the day, every day. The fix took one line: the crawler's requests set a header that makes the app skip writing to the cache on miss. Hot keys stopped being evicted overnight, and the 6 am hit rate returned to 94 percent.