Mastering Cache Penetration, Avalanche, and Breakdown: Interview-Ready Answers

In a typical cache workflow, a read request first checks the cache; if the value is present, it is returned immediately. If the cache misses, the system queries the database, writes the result back to the cache, and then returns the data.

1. Cache Penetration

1.1 What is cache penetration?

Cache penetration occurs when a request queries data that does not exist. Because the cache miss leads to a database query that also returns nothing, the system does not write anything to the cache, causing every subsequent request for the same nonexistent key to hit the database directly.

1.2 Causes of cache penetration

Unreasonable business logic : e.g., checking a user’s guard status for every request even though most users have never enabled it.

Malicious attacks : attackers deliberately generate massive requests for nonexistent data.

Data lifecycle issues : deleted data remains unrefreshed in the cache, leading to repeated misses.

Mitigation methods

Validate request parameters : perform format, range, and permission checks to filter obviously invalid requests before they reach the cache.

Cache null values : when a database query returns empty, store a placeholder or short‑TTL empty entry to prevent repeated DB hits.

Use a Bloom filter : a probabilistic data structure that quickly determines whether a key might exist. If the filter indicates non‑existence, the request bypasses the database entirely.

Bloom filter principle : It consists of a bitmap initialized to zero and N hash functions. Each key is hashed N times, setting the corresponding bits to 1. A lookup checks those bits; if any are 0, the key is definitely absent, otherwise it may exist.

2. Cache Avalanche

A cache avalanche happens when a large number of cached entries expire simultaneously, causing a sudden surge of database traffic that can overwhelm or crash the database.

2.1 Common causes

Uniform expiration times : many keys share the same or similar TTL, leading to collective expiration.

Insufficient cache warm‑up : after a system restart, the cache is empty, forcing many requests to hit the DB.

Cache server failures : multiple Redis nodes go down at once, making the cache unavailable.

Typical scenarios include the end of a promotion where many product caches expire together, or scheduled jobs that refresh caches at a fixed time (e.g., midnight batch updates).

2.2 Solutions

The simplest and most effective approach is to stagger expiration times. Instead of a single fixed TTL, add a random offset (e.g., 1 hour + 0‑100 seconds) to each key so expirations are dispersed.

For Redis failures, deploy high‑availability configurations such as master‑slave replication, Sentinel, or Redis Cluster.

Finally, apply rate limiting and graceful degradation as a safety net.

3. Cache Breakdown (Cache Stampede)

Cache breakdown refers to a hotspot key that expires while a burst of concurrent requests simultaneously query the database, causing a sharp spike in DB load.

Unlike a cache avalanche, which affects many keys, breakdown targets a single hot key, leading to short‑term pressure rather than a full‑scale outage.

3.1 Common causes

High concurrency scenarios such as flash sales or breaking news.

Manual accidental deletion of a hot key by operators.

3.2 Mitigation strategies

Use a mutex lock (e.g., Redis SETNX) so that only one request loads the DB and repopulates the cache; other requests retry fetching the cache.

"Never expire" pattern: keep the key without a TTL and refresh it asynchronously just before it would become stale.

Randomized TTLs for hot keys to avoid simultaneous expiration.