How to Prevent Redis Cache Penetration: Bloom Filters, Null Caching, and Rate Limiting

Redis is often used as a caching layer to relieve pressure on backend databases, but cache penetration can cause a flood of requests for nonexistent keys, wasting resources and potentially making services unavailable.

Bloom Filter Solution

Before accessing Redis, a Bloom filter checks whether a key might exist. If the filter determines the key is definitely absent, the request is rejected without hitting the database.

if (bloomFilter.exists(key)) → query Redis else → return empty

Pros: Efficiently blocks invalid requests, reduces database load, and uses minimal memory.

Cons: Possibility of false positives (rarely treating a non‑existent key as existing) and the need to maintain the filter’s update mechanism.

Cache Null Value Solution

When the database returns no result, cache a special “null” value in Redis. Subsequent queries for the same key return the cached empty result, avoiding another database hit.

Pros: Simple and effective, prevents repeated queries for missing data.

Cons: Heavy malicious traffic can still pressure Redis storage; short TTLs are required to prevent excessive space consumption.

Rate Limiting and Anti‑Scraping

Apply rate limiting, blacklists, or captchas to reduce malicious penetration attempts. Common implementations include Nginx + Lua, Sentinel, or API gateways.

Typical measures: limit request frequency, block or blacklist abnormal IPs, and add token or captcha verification for high‑risk endpoints.

Authentication and Business Validation

Many penetration requests contain obviously illegal parameters (e.g., userId = -1 or productId = 0). Validate parameter legality at the business layer to intercept such requests early.

if (userId <= 0) { return null; // do not query cache or database }

Pros: Stops invalid requests at the source with no extra system overhead.

Cons: Only catches clearly invalid parameters; cannot defend against random or sophisticated attacks.