How to Prevent Cache Penetration, Breakdown, and Avalanche in Redis

Cache Penetration

Cache penetration occurs when a large number of requests contain keys that are invalid – they do not exist in the cache and also do not exist in the database. These requests bypass the cache layer and hit the database directly, potentially overwhelming it.

Example: an attacker generates a massive number of illegal keys, causing every request to miss both cache and database and putting huge pressure on the database.

Mitigation Strategies for Cache Penetration

Validate request parameters early; reject obviously illegal values (e.g., negative IDs, malformed email formats) with an error response.

Cache null placeholder : when a key is missing in both cache and database, store a dummy value in Redis with a short TTL. Example command: SET key value EX 60 Short TTL (e.g., 60 seconds) limits attack amplification.

Standard key naming convention: table:column:primaryKey:primaryKeyValue Bloom filter : pre‑populate a Bloom filter with all valid keys. On each request, check the filter; if it reports the key does not exist, return an error without querying the database. For 1,000,000 elements the filter consumes about 122 KB.

Interface rate limiting per user or IP, optionally adding offending IPs to a blacklist.

Java example for caching null values:

public Object getObjectInclNullById(Integer id) {
    // Try cache first
    Object cacheValue = cache.get(id);
    if (cacheValue == null) {
        // Fallback to DB
        Object dbValue = storage.get(id);
        // Cache the result (including null)
        cache.set(id, dbValue);
        if (dbValue == null) {
            // Set a short expiration to avoid amplification
            cache.expire(id, 60 * 5); // 5 minutes
        }
        return dbValue;
    }
    return cacheValue;
}

Cache Breakdown (Cache Stampede)

Cache breakdown happens when a hot key exists in the database but is missing in the cache (usually because the cached entry expired). A sudden surge of requests for that hot data then all hit the database, potentially causing a crash.

Mitigation Strategies for Cache Breakdown

Set hot data to never expire or give it a long TTL.

Pre‑warm hot data before expiration (e.g., keep flash‑sale items cached until the sale ends).

Use a distributed mutex lock: before querying the database and writing to cache, acquire a lock so only one request performs the DB read while others wait for the cached result.

Cache Avalanche

A cache avalanche occurs when a large portion or all of the cache expires at the same time, or when the Redis service becomes unavailable. The sudden flood of requests then bypasses the cache and overwhelms the database.

Mitigation Strategies for Cache Avalanche

Deploy Redis in a cluster to avoid single‑node failure.

Apply rate limiting to smooth traffic spikes.

Use multi‑level caching (local + Redis) so that a Redis outage still allows partial data retrieval.

Randomize TTL for keys to prevent simultaneous expiration.

Cache pre‑warming: schedule tasks (e.g., with XXL‑Job) or use a message queue (e.g., Kafka) to repopulate hot data after startup or before expiration.

Differences Between the Three Issues

Cache penetration : the requested key is absent from both cache and database.

Cache breakdown (stampede) : the key corresponds to hot data that exists in the database but is missing in the cache, usually because the cached entry expired.

Cache avalanche : massive simultaneous cache expiration or cache service outage causes a flood of requests to the database.