Mastering Redis Cache Eviction: Strategies, Pitfalls, and Solutions

Interviewer: How does Redis cache eviction work?

Eviction Policies

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

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

Choosing the correct eviction policy is crucial and 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 for tuning.

Use allkeys-lru when you expect a power‑law distribution of accesses, making it a safe default choice.

Use allkeys-random for uniformly distributed accesses or when keys are scanned cyclically.

Use volatile-ttl when you want to control expiration by setting TTL values on cached objects.

allkeys-lru and volatile-random are useful when a single instance handles both caching and persistence of some keys, though running two instances is often a better solution.

Setting expiration times also consumes memory, so allkeys-lru can be more efficient when memory pressure is high.

How the Eviction Process Works

Understanding the eviction workflow is essential:

A client issues a new command that adds data.

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

Another command is executed, and the cycle repeats.

By repeatedly crossing the memory limit, Redis continuously evicts keys to stay below the threshold.

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

Interviewer: Cache Penetration, Breakdown, Avalanche, Warm‑up Solutions?

Cache Penetration

Cache penetration occurs when queries request data that never exists; because the cache is not written on a miss, each request hits the storage layer, defeating the cache's purpose and potentially crashing the database under high traffic.

Solutions

Common approaches include using a Bloom filter to block nonexistent keys, or caching empty results with a very short TTL (no more than five minutes).

Cache Breakdown

When a hot key expires and many concurrent requests simultaneously miss the cache, they all fall back to the database, which can become overwhelmed.

Solutions

Introduce random jitter to expiration times (e.g., add 1‑5 minutes) so that not all keys expire at once, reducing the chance of a collective cache miss.

Cache Avalanche

A cache avalanche happens when many keys share the same expiration time, causing them to expire simultaneously and flood the database with requests.

Solutions

1. Use a mutex (e.g., Redis SETNX) to ensure only one request loads data from the database and repopulates the cache. 2. Apply an "early" mutex by storing a short timeout inside the value; when it expires, extend it and reload the cache. 3. Implement "never expire" by storing logical expiration inside the value and refreshing the cache asynchronously, keeping the physical key alive.

Summary

Penetration: key does not exist in cache or DB, high concurrency, few keys.

Breakdown: key expires in cache but exists in DB, high concurrency, few keys.

Avalanche: many keys expire together, high concurrency, many keys.

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