Redis Eviction Policies: Eight Choices, and Only One Is Right for Your Workload

Keys do not disappear from Redis randomly. maxmemory sets the ceiling, and maxmemory-policy decides who leaves when the ceiling is hit. Redis ships eight policies, and most teams never look past the default.

noeviction refuses new writes once memory is full and lets reads continue. It is the right choice when the data is not regenerable. The allkeys-* family considers every key. The volatile-* family only considers keys that have an explicit TTL, which is how you signal "this is cache" inside an instance that also holds non-cache data. Inside each family you choose between LRU, LFU, random, and (for volatile) TTL. LRU is approximate in Redis: it samples five keys at eviction time and removes the coldest of the sample, not the true least-recently-used key in the whole keyspace. LFU goes further and tracks a logarithmic access counter per key, so a key hit a million times stays hot for a long time after the traffic dies down. LFU is almost always the right cache policy under skewed traffic.

The production failure I keep seeing involves a team that ran one Redis instance for both their HTTP cache (TTLs around five minutes) and their session store (no TTL, the session lives until logout). They had maxmemory-policy allkeys-lru set because that was the cluster template. Cache pressure rose during a marketing campaign, memory crossed maxmemory, and allkeys-lru happily evicted whichever keys looked coldest. Session keys are rarely touched between requests, so they looked cold. Logged-in users started getting bounced to the sign-in page mid-checkout. Support tickets blamed the SSO provider for two weeks before anyone correlated the incidents with cache pressure on Redis.

The fix had two layers. The clean answer is to split instances: a cache Redis with allkeys-lfu, and a session Redis with noeviction and a memory quota big enough to hold the session footprint with headroom. The cheaper answer, when a second instance is not in the budget that quarter, is to switch the shared instance to volatile-lfu. Cache entries already had TTLs, so they were the only eviction candidates. Session keys, which had no TTL, became untouchable by the eviction algorithm. The bug stopped that afternoon.

There is one more knob worth knowing. Set maxmemory-samples higher than the default of five if you care about eviction accuracy. Ten gives noticeably better choices for a small CPU cost. Below five and eviction starts to look random in practice.

The policy is not a tuning detail. It is a contract about which keys the instance is allowed to forget.