Mastering Redis Cache Eviction: Strategies to Prevent Penetration, Breakdown & Avalanche

Interview Question: How does Redis cache eviction work?

Eviction Strategies

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 key to make space for new data.
volatile-lru: evicts the least recently used key among keys with an expiration set.
allkeys-random: evicts a random key to make space.
volatile-random: evicts a random key among keys with an expiration set.
volatile-ttl: evicts keys with an expiration set, 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 key satisfies the eviction preconditions, the behavior is similar to noeviction for volatile-lru , volatile-random and volatile-ttl .

Choosing the right eviction strategy depends on your application's access pattern; you can adjust the policy at runtime and monitor cache hit/miss rates via the Redis INFO command.

General guidelines:

Use allkeys-lru when the request distribution follows a power‑law, i.e., a small subset of keys is accessed much more frequently.

Use allkeys-random for uniformly accessed keys or when scanning all keys sequentially.

Use volatile-ttl when you want expiration time to decide which objects should be removed.

allkeys-lru and volatile-random are useful when a single instance implements caching and persistence for some keys; however, running two instances is generally a better solution.

Setting expiration for keys consumes memory; therefore allkeys-lru is more efficient when memory pressure is high because it does not require per‑key expiration.

How the Eviction Process Works

The process is:

A client issues a command that adds new data.

Redis checks memory usage; if it exceeds maxmemory, it evicts keys according to the configured policy.

The new command is then executed, and the cycle repeats.

If a command causes a large memory allocation (e.g., storing the result of a massive set operation), the memory limit can be exceeded quickly.

Interview Question: Solutions for Cache Penetration, Breakdown, and Avalanche

Cache Penetration

Cache penetration occurs when queries for non‑existent data repeatedly miss the cache and hit the database, potentially overwhelming it under high traffic.

Solutions

Common approaches include using a Bloom filter to block requests for definitely absent keys, or caching empty results with a very short TTL (e.g., up to five minutes).

Cache Breakdown

When a hot key expires, a sudden surge of requests may simultaneously miss the cache and hit the database, risking overload.

Solutions

Distribute expiration times by adding a random offset (e.g., 1–5 minutes) to each key's TTL, or use a mutex (e.g., Redis SETNX) to ensure only one request rebuilds the cache while others wait.

Cache Avalanche

Cache avalanche happens when many keys share the same expiration time and expire together, causing a massive spike of database traffic.

Solutions

Use mutex locks, stagger expiration times, or implement logical expiration where the actual data persists while a background thread refreshes the cache.

Summary

Penetration: non‑existent key, DB also missing, high concurrency, few keys.

Breakdown: key missing in cache but present in DB, high concurrency, few keys.

Avalanche: many keys missing in cache, DB present, high concurrency, many keys.

All scenarios can be mitigated with rate‑limiting mutexes to protect the database.