How to Prevent Cache Penetration, Breakdown, and Avalanche in Backend Systems

Introduction

For backend developers, caching is essential for performance, but misuse can cause serious issues. The article outlines three major cache problems and how to address them.

1. Cache Penetration

1.1 How caching works

Typical flow: check cache → if hit, return data; if miss, query DB → if DB returns data, store in cache and return; if DB also misses, return failure.

1.2 What is cache penetration?

When a request queries a non‑existent key (or a maliciously forged key), the cache always misses, forcing a DB query each time. This defeats caching and can overload the DB.

1.3 Mitigation: Parameter validation

Validate request IDs (e.g., only IDs starting with 15 are allowed). Invalid IDs are rejected early, filtering out many malicious requests.

1.4 Bloom filter

For small datasets, preload all existing keys into an in‑memory map. For large datasets, use a Bloom filter:

If all bits for a key are 1, the key likely exists → allow DB query.

If any bit is 0, the key definitely does not exist → reject request.

Bloom filters reduce DB load but introduce false‑positive errors and require synchronization when DB data changes.

1.5 Cache empty values

When a key is missing in both cache and DB, store a placeholder empty value in the cache. Subsequent requests hit the cache and avoid DB queries.

2. Cache Breakdown (Cache Stampede)

2.1 What is cache breakdown?

When a hot key expires, many concurrent requests bypass the cache and hit the DB simultaneously, potentially crashing it.

2.2 Locking

Use a distributed lock (e.g., Redis SET key value NX PX expire) so that only one request queries the DB while others wait or receive the cached result after it is refreshed.

try {
    String result = jedis.set(productId, requestId, "NX", "PX", expireTime);
    if ("OK".equals(result)) {
        return queryProductFromDbById(productId);
    }
} finally {
    unlock(productId, requestId);
}
return null;

2.3 Automatic renewal

Schedule a job to refresh hot keys before they expire (e.g., every 20 minutes for a 30‑minute TTL) to keep them alive.

2.4 Non‑expiring cache for hot keys

For extremely hot items (e.g., flash‑sale products), keep them permanently cached and manually delete after the event.

3. Cache Avalanche

3.1 What is cache avalanche?

Multiple hot keys expire simultaneously or the cache server crashes, causing a massive surge of DB traffic.

3.2 Randomized expiration

Add a random offset (1–60 seconds) to each key’s TTL to stagger expirations:

actualTTL = baseTTL + random(1, 60);

3.3 High availability

Deploy Redis in Sentinel or cluster mode so that a master failure triggers automatic failover.

3.4 Service degradation

When the cache is unavailable, switch to a fallback mode: use default data from a configuration center after a threshold of recent cache failures, and restore normal operation once the cache recovers.

Conclusion

Cache penetration, breakdown, and avalanche each require specific safeguards—parameter checks, Bloom filters, empty‑value caching, distributed locks, renewal jobs, randomized TTLs, HA architectures, and graceful degradation—to keep backend systems stable under high load.