Redis Cache Eviction Strategies and Solutions for Penetration, Breakdown, and Avalanche

In an interview‑style discussion, the article introduces Redis cache eviction strategies, listing the available policies and their behavior:

noeviction: returns an error when memory limit is reached and a client tries to execute a command that would use more memory (most write commands, except DEL and a few others)
allkeys-lru: tries to evict the least recently used keys to make space for new data.
volatile-lru: evicts the least recently used keys, but only among keys with an expiration set.
allkeys-random: evicts random keys to free space.
volatile-random: evicts random keys, limited to keys with an expiration.
volatile-ttl: evicts keys with an expiration, preferring those with the shortest remaining TTL.
volatile-lfu: evicts the least frequently used keys among those with an expiration.
allkeys-lfu: evicts the least frequently used keys among all keys.

If no keys satisfy the preconditions for eviction, the policies volatile-lru , volatile-random , and volatile-ttl behave similarly to noeviction .

Choosing the right eviction policy is crucial and depends on the application's access pattern; policies can be adjusted at runtime and monitored via the Redis INFO command to tune hit‑rate and miss‑rate.

General practical guidelines include:

Use allkeys-lru when the workload follows a power‑law distribution, making it a safe default.

Use allkeys‑random for uniformly distributed access or when keys are scanned sequentially.

Use volatile‑ttl when you want expiration to be driven by TTL values set at cache‑object creation.

The allkeys‑lru and volatile‑random policies are useful for a single instance that persists some keys, though running multiple instances is often a better solution.

Setting expiration for keys consumes memory; therefore allkeys‑lru can be more efficient under memory pressure because it avoids the overhead of per‑key TTL metadata.

How the Eviction Process Works

The eviction cycle proceeds as follows:

A client issues a command that adds new data.

Redis checks memory usage; if it exceeds maxmemory , it applies the configured eviction policy.

The process repeats as new commands arrive, continuously pushing memory usage back below the limit.

If a command generates a large amount of data (e.g., storing the result of a massive set intersection), the memory limit can be exceeded quickly, triggering eviction.

Cache Penetration, Breakdown, Avalanche, and Warm‑up Solutions

Cache Penetration

Penetration occurs when requests query data that does not exist; because the cache does not store a negative result, every request hits the database, potentially overwhelming it under high traffic.

Solutions include using a Bloom filter to pre‑filter nonexistent keys, or caching empty results with a very short TTL (e.g., up to five minutes).

Cache Breakdown (Stampede)

When a hot key expires, a surge of concurrent requests may simultaneously query the database, causing a sudden load spike.

Typical mitigations involve serializing cache rebuilds with a mutex/lock or queue, and adding a random jitter to TTLs (e.g., 1–5 minutes) to stagger expirations.

Cache Avalanche

Avalanche happens when many keys share the same expiration time and expire together, flooding the database with requests.

Mitigation techniques include:

Using a mutex key (e.g., Redis SETNX ) to ensure only one request rebuilds the cache.

Applying a “pre‑lock” with a shorter internal timeout than the actual cache TTL.

Implementing “never expire” logical expiration: store the logical expiration inside the value and refresh it asynchronously, allowing the physical key to persist.

Summary

Penetration: non‑existent cache key, DB miss, high concurrency, few keys.

Breakdown: cache miss for an existing key, DB hit, high concurrency, few keys.

Avalanche: simultaneous cache miss for many keys, DB overload, high concurrency, many keys.

Although terminology varies slightly, all scenarios can be mitigated with rate‑limiting mutexes to protect database stability.