Backend Development 5 min read

How to Prevent Redis Cache Penetration: Bloom Filter, Null Caching, Pre‑warming, and Rate Limiting

This article explains why Redis cache penetration occurs and presents four practical mitigation techniques—using a Bloom filter, caching placeholder values, pre‑warming hot keys, and applying authentication with rate‑limiting—to protect backend performance and database stability.

Architect Chen

Dec 4, 2025

Redis is a cornerstone of large‑scale architectures, but cache penetration—repeated requests for nonexistent keys—can overload the database. The article outlines four effective strategies to stop penetration.

Bloom Filter

A Bloom filter is a highly space‑efficient probabilistic data structure that stores all potentially existing keys in a large bit array. When a request arrives, the filter quickly determines if the key is definitely absent (block the request) or possibly present (allow the request to reach Redis and the database). Advantages include massive memory savings; the drawback is a false‑positive rate, meaning some nonexistent keys may be mistakenly allowed.

Caching Empty Values

When the application discovers that a key does not exist in the database, it should write a special placeholder (e.g., a specific string, null, or a default object) into Redis with a short TTL (typically 5–10 minutes). This instantly satisfies subsequent identical requests and prevents DB hits. The trade‑off is additional memory consumption for many meaningless keys, and the need to set an expiration to avoid serving stale empty values after real data appears.

Cache Pre‑warming

This technique targets non‑malicious first‑time penetration, such as during system startup or before a traffic surge. After updating hot data, proactively load the most frequently accessed keys into Redis so they are already cached when traffic arrives, dramatically improving hit rates. However, it cannot defend against deliberate random key attacks.

Authentication and Business Validation

For malicious attacks, implement circuit‑breaker and rate‑limiting mechanisms as a final safeguard. Validate request parameters (e.g., user ID, product ID) for correct format, length, and range at the API gateway or business logic layer, rejecting obviously illegal requests. Use tools such as Nginx, Sentinel, or Guava RateLimiter to limit the number of requests per user ID or IP within a time window; exceedances return error codes or trigger circuit breaking.