Cache Breakdown (Cache Penetration) and Mitigation Strategies: Mutex Lock, Asynchronous Cache, and Bloom Filter

Cache breakdown occurs when repeated requests for data that is absent in the cache force every request to hit the underlying storage, potentially overwhelming the database under high traffic.

The article first reviews the basic cache‑loading flow and then defines cache breakdown, describing how attackers can generate numerous nonexistent keys to bypass the cache.

Solution Overview : Three approaches are offered, each leveraging Redis features.

SETNX is introduced as the atomic "set if not exists" command, which returns 1 on success and 0 on failure, with O(1) time complexity.

1. Mutex Lock : When a cache miss occurs, a lock is acquired (using a local Lock in single‑node environments or Redis SETNX for distributed setups) before loading data from the database; other threads wait and retry after a short sleep. Advantages: simple logic and consistency; disadvantages: increased code complexity and potential deadlocks.

2. Asynchronous Cache Rebuild : Cache updates are delegated to a thread pool, allowing the original request to return the stale value while a background task refreshes the cache. This reduces latency for users but cannot guarantee cache consistency.

3. Bloom Filter : A probabilistic data structure that quickly determines if an element is possibly in a set, preventing unnecessary database hits for keys that are definitely absent. The article explains the bit array, hash functions, false‑positive rate, and shows example calculations and diagrams.

Performance Test : Using a Maven project with Guava, the test demonstrates that checking membership in a million‑element set takes about 0.219 ms, and a default false‑positive rate of 0.03 is observed when testing 10,000 non‑existent elements.

The Bloom filter’s false‑positive rate can be tuned (e.g., to 0.01) by adjusting the bit array size, which increases memory usage.

Practical Redis Pseudocode for integrating a Bloom filter is provided, highlighting its simplicity, consistency, and strong performance, while noting drawbacks such as increased code complexity, the need for an auxiliary key store, and the inability to delete entries.

Conclusion : The three mitigation strategies each have trade‑offs; developers should choose based on project requirements, balancing simplicity, consistency, performance, and resource consumption.