Handling Cache Penetration, Breakdown, and Avalanche in Backend Systems

Designing a cache system inevitably requires dealing with three classic problems: cache penetration, cache breakdown, and cache avalanche, which can cause severe pressure on the underlying database under high traffic.

Cache Penetration occurs when a request queries data that does not exist. Because the cache does not store a negative result, every request hits the database, potentially overwhelming it and exposing a denial‑of‑service vulnerability.

Common solutions include using a Bloom filter to pre‑filter impossible keys, or caching empty results for a very short period (no more than five minutes) so that repeated queries are blocked at the cache layer.

Cache Avalanche happens when many cached items share the same expiration time and expire simultaneously, causing a sudden surge of database requests.

Mitigation typically involves adding a random offset (e.g., 1‑5 minutes) to each key’s TTL, thereby dispersing expiration events and preventing a collective overload.

Cache Breakdown refers to a hot key that expires and is immediately accessed by a massive number of concurrent requests, leading to a burst of database reads.

One effective approach is to use a mutex (distributed lock) so that only a single thread rebuilds the cache while others wait. The article provides concrete pseudo‑code for both Memcache and Redis implementations.

Memcache example:

if (memcache.get(key) == null) {
    // 3 min timeout to avoid mutex holder crash
    if (memcache.add(key_mutex, 3*60*1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
}

Redis example:

String value = redis.get(key);
if (value == null) {
    if (redis.setnx(key_mutex, "1")) {
        // 3 min timeout to avoid mutex holder crash
        redis.expire(key_mutex, 3*60);
        value = db.get(key);
        redis.set(key, value);
        redis.delete(key_mutex);
    } else {
        // other threads sleep 50ms then retry
        Thread.sleep(50);
        get(key);
    }
}

The article then compares four mitigation strategies:

Simple Distributed Lock (Tim Yang) – easy to understand, ensures consistency, but adds code complexity and risk of deadlock.

Additional Expiration Time – also ensures consistency with similar drawbacks.

Never‑Expire (Logical Expiration) – stores a logical timeout inside the value and rebuilds the cache asynchronously; improves latency but does not guarantee strict consistency.

Hystrix Resource Isolation – uses thread‑pool isolation to protect the backend; mature but may introduce fallback behavior.

For high‑concurrency internet services, the goals are to accelerate user access, reduce backend load, and keep data reasonably fresh. No single solution is universally best; the appropriate method depends on the specific workload and consistency requirements.

Conclusion : Hot keys combined with expiration and complex cache‑building logic lead to mutex‑key problems; using a single thread to rebuild the cache mitigates the issue. Among the four approaches, there is no absolute winner—only the most suitable one for the given scenario.