Choosing the Right Redis Eviction Strategy and Handling Cache Failures

Redis Eviction Policies

Redis can be configured with a maxmemory limit. When the limit is reached, Redis applies one of several eviction policies defined by the maxmemory-policy setting.

noeviction      – Returns an error for commands that would increase memory usage.
allkeys-lru     – Evicts the least‑recently‑used key among all keys.
volatile-lru   – Evicts the LRU key among keys that have an expiration set.
allkeys-random – Evicts a random key among all keys.
volatile-random– Evicts a random key among keys with an expiration.
volatile-ttl   – Evicts keys with an expiration, preferring those with the shortest TTL.
volatile-lfu   – Evicts the least‑frequently‑used key among keys with an expiration.
allkeys-lfu     – Evicts the least‑frequently‑used key among all keys.

If no keys satisfy the criteria for a volatile‑* policy, the behavior falls back to noeviction.

Typical guidance:

allkeys-lru : Works well when access follows a power‑law distribution (a small hot set of keys). Good default when the pattern is unknown.

allkeys-random : Suitable for uniform access patterns or round‑robin workloads.

volatile-ttl : Preferable when you explicitly set TTLs and want keys with shorter remaining lifetimes to be evicted first.

How the Eviction Process Works

A client issues a command that creates or modifies data.

Redis checks the current memory usage against maxmemory.

If the limit would be exceeded, Redis selects keys according to the configured policy and removes them.

The original command then proceeds. Repeated writes that keep memory usage above the limit cause continuous evictions until usage falls below the threshold.

Large operations (e.g., storing the result of a massive set intersection) can cause an abrupt spike that triggers immediate eviction.

Cache Failure Patterns and Mitigation Strategies

Cache Penetration

Occurs when a request queries a key that does not exist in both the cache and the backing database. Because the cache does not store a negative result, every request hits the database, potentially overwhelming it under high concurrency.

Mitigation

Deploy a Bloom filter to pre‑check whether a key could exist; non‑existent keys are filtered out before reaching the database.

Cache empty results with a very short TTL (e.g., 1–5 minutes) so that repeated requests for the same missing key do not repeatedly hit the database.

Cache Breakdown (Stampede)

When a cached key expires, many concurrent requests may simultaneously attempt to rebuild the value, causing a sudden surge of database traffic.

Mitigation

Add random jitter to the expiration time (e.g., +1–5 minutes) so that keys do not expire at the same instant.

Use a mutex (e.g., SETNX in Redis) or a distributed lock so that only one request rebuilds the cache while others wait or serve stale data.

Cache Avalanche

When a large number of keys share the same TTL, they may expire together, generating a massive burst of database queries.

Mitigation

Apply a mutex key (using SETNX or similar) so that the first request after a miss loads data from the database and repopulates the cache; subsequent requests retry the get operation.

Store an internal short timeout ( timeout1) inside the cached value that is smaller than the external cache TTL ( timeout2). When timeout1 expires, extend it and refresh the cache asynchronously.

Implement logical expiration: embed a logical expiration timestamp in the value, serve stale data while a background thread refreshes the cache.

Summary of Failure Types

Penetration : Key missing in both cache and DB, high concurrency, few keys.

Breakdown (Stampede) : Key missing in cache but present in DB, high concurrency, few keys.

Avalanche : Many keys missing in cache but present in DB, high concurrency, large key set.

All three scenarios can be mitigated with rate limiting, mutex locks, or staggered expirations to protect the underlying database.