Cache Penetration, Breakdown, and Avalanche: Redis Cache Problems

These are three distinct failure modes. Cache penetration is when requests query keys that exist in neither the cache nor the database — for example, an attacker hitting /user/-1 repeatedly. The cache never gets populated so every request hits the DB. Two defenses: cache the null result with a short TTL (say 60s) so repeated attacks are absorbed by Redis, and put a Bloom filter in front — on startup or on write, add every valid ID to the filter, and reject queries that miss the filter. Bloom filters have false positives but never false negatives, so they're safe for this use case. Cache breakdown is different — the data exists, but a single hot key expires, and before anyone can rebuild the cache, thousands of concurrent requests pile up on the DB. The fix is either a mutex — the first request to miss acquires a short-lived Redis lock and rebuilds, everyone else waits or returns stale — or "logical never expire", where the cache never actually expires but carries a logical expiry timestamp inside the value; when it's past logical expiry, one thread asynchronously refreshes while others keep serving the stale data. Cache avalanche is when many keys expire at the same moment, or Redis itself goes down — the DB gets hit by the full read load and often collapses. Defenses are layered: first, jitter TTLs — instead of setting every key to exactly 3600s, use 3600 + random(0, 600), so expirations spread over time. Second, add a local in-process cache (Caffeine in Java, Guava) in front of Redis — even if Redis dies, each JVM serves from its own memory for a minute. Third, put circuit breakers and rate limiters on the DB path so when the DB falls behind, it fails fast instead of piling up connections. Fourth, run Redis with Sentinel or Cluster so a single node failure doesn't drop the whole cache. In production, I combine all of these — Bloom filter + null cache + TTL jitter + local cache + circuit breaker — rather than picking one.