Five Fatal Cache Pitfalls Explained with Five Diagrams

Using a cache does not guarantee system stability; issues like penetration, concurrency, and avalanche can still crash the database. This article presents five typical cache pitfalls and practical Redis‑based remedies, each illustrated with a diagram.

Problem 1: Cache Penetration – block malicious requests with placeholder values

When a key is absent in both cache and database, repeated requests bypass the cache and hit the database, potentially overwhelming it. The simple fix is to store a sentinel value (e.g., the string "Null") for nonexistent keys so subsequent requests see the placeholder and avoid a DB lookup. Bloom filters can also pre‑filter requests but have false‑positive rates and higher complexity.

Problem 2: Cache Concurrency (Cache Stampede) – use setNX for a distributed lock

Imagine a hot item’s cache expires and 1,000 requests simultaneously miss, all querying the DB and rewriting the cache 1,000 times. This wastes DB resources and fills the cache. The core solution is to employ Redis setNX as a lock: the first request that acquires the lock reads the DB and updates the cache; the others wait and retry, hitting the refreshed cache.

Problem 3: Cache Avalanche – add a random offset to TTL

Setting a fixed expiration (e.g., 5 minutes) for many keys causes them to expire together; a sudden traffic surge then floods the DB, leading to a crash. The remedy is to add a random component (e.g., 1–10 minutes) to each key’s TTL, spreading expirations over time. An alternative is to keep keys permanent and refresh them asynchronously via a background job, suitable for low‑frequency data changes.

Problem 4: Hot Data – use a sorted‑set queue to cache only the most popular items

Cache space is limited, so deciding which data to keep is crucial. For an e‑commerce site, cache the top 1,000 most‑visited products using a Redis ZSET. Each access updates the product’s timestamp score via zadd. Periodically, remove the lowest‑ranked 200 items with zrange and replace them with new random products from the DB. This self‑organizing queue automatically promotes hot items and evicts cold ones without extra computation.

Problem 5: Decoupling Cache from Business Logic – Binlog → Canal → MQ → Redis

When cache code is mixed with business code, changes become risky as a single cache tweak may affect multiple modules. The standard decoupling approach uses three steps: MySQL generates binlog events; Canal captures and parses these events; the parsed changes are sent to a message queue; a dedicated cache service consumes the messages and updates Redis. This separation follows the “high cohesion, low coupling” principle.

Overall, cache design starts with acceleration, then must address penetration, concurrency, and avalanche. After stabilizing these scenarios, manage limited cache capacity with a sorted‑set hot‑data strategy, and finally decouple cache updates from business code via a Binlog‑Canal‑MQ pipeline to improve maintainability.