Preventing Redis Cache Inconsistency, Avalanche, Breakdown, and Penetration

When using Redis as a cache, ensuring consistency between the cache and the database is essential. Consistency means either the cache holds the same data as the database or the cache is empty while the latest value resides in the database.

To maintain consistency for read‑write caches, a synchronous write‑through strategy combined with transactional mechanisms should be used to guarantee atomic updates. In scenarios where strict consistency is not required, an asynchronous write‑back strategy may be acceptable.

Read‑only caches naturally satisfy the second consistency case, but during delete or update operations, a failure in either the cache or the database can cause inconsistency. A retry mechanism using a message queue can mitigate this: failed operations are re‑queued, retried, and removed from the queue upon success, with alerts for repeated failures.

High concurrency can still lead to stale reads. Depending on whether the cache or the database is updated first, a “delayed double delete” approach can be applied to ensure consistency. Example code:

redis.delKey(X)
 db.update(X)
 Thread.sleep(N)
 redis.delKey(X)

Illustrations of the situation and solutions are shown in the accompanying diagrams.

2. Cache Avalanche

A cache avalanche occurs when a large number of requests bypass Redis and hit the database, overwhelming it. This can happen because many cached items expire simultaneously or because the Redis instance fails.

To address expiration spikes, stagger expiration times (e.g., add random delays) or implement degradation handling: return empty or error responses for non‑critical data while allowing critical data to query the database.

If the Redis instance crashes, apply circuit breaking to reject cache client requests until the cache recovers, or use rate limiting to allow only a portion of requests to reach Redis, reducing database load.

3. Cache Breakdown

Breakdown refers to a hot key that is not cached, causing a flood of requests to the database. For extremely hot data, omit expiration so the data stays in the cache permanently.

4. Cache Penetration

Penetration happens when requested data is absent from both Redis and the database, still sending traffic to the database. Common causes include accidental data deletion or malicious attacks.

Three mitigation strategies:

Cache empty or default values : Store a placeholder in Redis for missing data to prevent database hits.

Bloom filter : Use a bit array with multiple hash functions to quickly test whether a key might exist before querying the database.

Front‑end request filtering : Validate request parameters at the entry point and discard obviously invalid or malicious requests.

Summary

Cache avalanche and breakdown stem from data missing in the cache, while penetration occurs when data is missing in both cache and database. Preventive measures include proper expiration settings, high‑availability cache clusters, avoiding expiration for hot keys, and implementing request validation or Bloom filters.

Lossy solutions such as circuit breaking, degradation, and rate limiting protect system stability but may degrade user experience; therefore, proactive prevention is recommended.