How to Prevent Cache Penetration and Cache Breakdown: Proven Strategies and Trade‑offs

Background

As internet applications become ubiquitous, almost every online service relies on caching to handle sudden traffic spikes or sustained high load. However, caching introduces two critical risks: cache penetration (queries for non‑existent data repeatedly hit the database) and cache breakdown (cached data expires, causing a surge of database requests).

Common Solutions for Cache Penetration

1. Null Cache (Empty Value)

When a key is known to be absent, store a placeholder (null or an empty string) in the cache. Subsequent requests retrieve the placeholder without hitting the database, reducing load.

These placeholder entries must have a TTL (time‑to‑live) or an update mechanism to avoid stale empty values when the data later appears.

Drawbacks include wasted cache space for many sparse keys and vulnerability to malicious attacks that can fill the cache with empty entries. A common mitigation is to count requests for a missing key and only query the database when the count exceeds a threshold.

2. Bloom Filter

A Bloom filter is a probabilistic data structure that can quickly tell whether an element is definitely absent or possibly present. It uses multiple hash functions to set bits in a bit array.

Typical usage: insert all existing keys into the filter; on a request, first check the filter—if it reports “definitely not present,” return null immediately; otherwise fall back to the database.

Key points:

The filter must use efficient hash functions such as MurmurHash or FNV.

It does not support deletions, so deleted keys remain marked as present; combine it with null caching for deletions.

It cannot be resized; the size must be estimated upfront based on expected key count, false‑positive rate (p), and number of hash functions (k) using the formula m = -(n * ln(p)) / (ln(2)^2).

Common Solutions for Cache Breakdown

1. Mutex Lock (Redis SETNX)

When a cache entry expires, acquire a distributed lock (e.g., a Redis key set with SETNX). Only the client that obtains the lock queries the database and repopulates the cache; others retry or return empty.

try {
    Boolean snx = redisClient.setNX(redisKey, value);
    if (snx && timeout > 0) {
        boolean flag = redisClient.expire(redisKey, timeout, unit);
        if (!flag) {
            redisClient.del(redisKey);
        }
        return flag;
    }
} catch (Exception e) {
    LOG.error("setnx: key=" + redisKey, e);
}
return false;

Since SETNX and EXPIRE are not atomic, Redis 2.6.12+ provides the SET key value NX EX seconds command, which atomically sets the lock with an expiration.

This approach works well for rarely‑expiring keys but can cause database overload or thread blockage if many keys expire simultaneously (cache avalanche) or if database queries are slow.

2. Asynchronous Cache Build

Instead of blocking the request, submit an asynchronous task to rebuild the cache and immediately return a null or default response. This reduces request latency and protects the database, at the cost of temporary data inconsistency.

It is suitable for scenarios where eventual consistency is acceptable.

Summary

The table below compares the typical methods for handling cache penetration and cache breakdown, highlighting their pros and cons.