Preventing Cache Avalanche, Breakdown, and Penetration: Effective Strategies and Patterns

1. Cache Avalanche

When a large number of cached entries expire simultaneously, the sudden loss of cache forces a flood of requests onto the database, overwhelming its CPU and memory and potentially causing a crash.

How to prevent cache avalanche

Mutex lock queue : Use a Redis SETNX to create a mutex key; only the request that acquires the lock loads data from the database and repopulates the cache, while others retry.

Data pre‑warming : Load critical data into the cache proactively after system startup, optionally using a reload mechanism before a predicted traffic spike.

Dual‑cache strategy : Maintain a primary cache (C1) with a short TTL and a secondary cache (C2) with a long TTL; when C1 expires, reads fall back to C2.

Timed cache refresh : For data with low freshness requirements, initialize the cache at container start and update or evict it via scheduled jobs.

Staggered expiration : Assign different TTLs to keys so that they do not all expire at the same moment.

2. Cache Breakdown (Cache Stampede)

A cache breakdown occurs when many concurrent requests query the same key exactly as it expires, causing all of them to hit the database simultaneously.

Solution

Apply a mutex lock on the first request that detects a miss; other requests wait for the lock, and once the data is loaded and cached, subsequent requests read from the cache.

3. Cache Penetration

Cache penetration happens when requests query keys that do not exist in the database; the cache has no entry, so every request bypasses the cache and hits the database, wasting resources.

Mitigation techniques

Cache empty values : Store a short‑lived placeholder for nonexistent results (e.g., 5 minutes) to prevent repeated database hits.

Bloom filter : Use a memory‑efficient probabilistic data structure to test key existence before querying the cache or database; non‑existent keys are filtered out early.

4. Common Cache Patterns

Cache‑Aside

Application reads from the cache first; on a miss, it fetches from the database, returns the data, and writes it back to the cache. Writes update the database and then invalidate the corresponding cache entry.

Note: Updating the cache immediately after a write can cause race conditions and stale data if concurrent reads occur.

Read/Write‑Through

All reads and writes go through the cache service, which synchronously propagates writes to the database. This reduces the chance of dirty data but creates a strong dependency on cache availability.

Write‑Behind (Write‑Back)

Writes are performed against the cache and asynchronously persisted to the database via background tasks. This offers high throughput but sacrifices consistency and may risk data loss if the async process fails.