Cache Penetration, Cache Breakdown, and Cache Avalanche: Concepts and Mitigation Strategies

Cache Penetration

Concept

When a user queries data, the request first checks the Redis in‑memory cache; if the cache misses, the query proceeds to the persistent database. If the database also lacks the data, the query fails. Under heavy traffic, many cache misses cause a surge of requests to the database, potentially overwhelming it—a situation known as 缓存穿透.

Solutions

1. Bloom Filter

A Bloom filter stores all possible query keys in a hashed form. Before accessing the storage layer, the filter validates the key; non‑matching keys are discarded, preventing unnecessary database queries.

2. Cache Empty Objects

When the storage layer returns an empty object, it is cached with an expiration time. Subsequent requests retrieve the empty result from the cache, reducing load on the backend. However, this approach can increase cache size and introduce temporary inconsistency between cache and storage.

Cache Breakdown (Cache Stampede)

Concept

A cache breakdown occurs when a highly hot key expires and a massive number of concurrent requests simultaneously miss the cache, directly hitting the database. This sudden surge can cause severe database pressure.

Solutions

1. Set Hot Data to Never Expire

By keeping hot keys permanent in the cache, expiration‑induced stampedes are avoided.

2. Add Mutual Exclusion (Distributed Lock)

Using a distributed lock ensures that only one thread queries the backend and repopulates the cache for a given key, while other threads wait, shifting the concurrency pressure to the lock mechanism.

Cache Avalanche

Concept

A cache avalanche happens when many cached entries expire simultaneously, causing a massive influx of requests to the database and creating periodic pressure spikes. More severe is when an entire cache node fails or loses network connectivity, leading to unpredictable and potentially catastrophic load on the database.

Solutions

1. Redis High Availability

Deploy multiple Redis instances in a cluster so that the failure of a single node does not disrupt the overall caching service.

2. Rate Limiting and Degradation

After cache expiration, control the number of threads that read from the database and write back to the cache by using locks or queues, allowing only one thread to perform the operation per key.

3. Data Pre‑warming

Before a major traffic event, proactively access likely hot data to populate the cache and stagger expiration times across keys, smoothing out load spikes.