Why Cache Isn't a Magic Bullet: How Redis Can Still Overload Your Database

After learning micro‑services and service governance, the author describes a typical e‑commerce flow where requests enter through a gateway, are load‑balanced to services such as order, inventory, and payment, and then hit the database.

01 Why Cache Is Needed

When a popular product page receives hundreds of thousands of views, repeatedly querying the database creates heavy load and slow responses. Since the displayed data (title, image, price, description, category, partial stock) changes infrequently, it can be stored in a cache. With cache, the request path changes to: user → application → Redis → (hit) return result or (miss) query database.

02 Understanding Cache

The author likens the database to a warehouse and Redis to a front‑store shelf: the warehouse holds the complete, authoritative data but is slow; the shelf holds frequently accessed hot items for quick retrieval. The principle "cache: read less from slow resources" means placing frequently accessed, rarely changing data in a faster layer.

03 What Redis Is

Redis is described as an in‑memory high‑speed data‑structure server used mainly for caching. Its speed comes from keeping data in memory and fast key lookups. The author lists the five common Redis data types with simple mnemonics: String (store a value), Hash (store an object), List (queue), Set (deduplicate), ZSet (ordered with scores).

04 Multi‑Level Cache: Closer to the User, Faster

Beyond Redis, architectures often include CDN, Nginx local cache, Redis, and the database. CDN caches static assets near users, Nginx can cache hot pages or API results, Redis caches hot business data, and the database remains the source of truth. The request chain becomes: User → CDN → Nginx → Redis → Database, with proximity to the user improving latency and proximity to the database improving data authority.

05 Cache Is Not a Panacea

Initially the author thought adding cache would automatically speed up the system, but discovered cache can also cause problems. The three common cache issues are cache avalanche, cache penetration, and cache breakdown.

06 Cache Avalanche (Many Keys Expire Simultaneously)

An avalanche occurs when a large number of keys expire at the same time, causing a sudden surge of requests to the database. Example: many caches set to expire at 12:00 all become invalid, and the next moment all user requests miss Redis and hit the database, overwhelming it. Mitigations include adding random jitter to TTLs, keeping hot data from expiring, using multi‑level cache, and applying rate limiting or circuit breaking when necessary.

07 Cache Penetration (Querying Non‑Existent Data)

Penetration happens when requests query data that does not exist in either cache or database, such as productId = -1, -2, or an extremely large ID. Each request still passes through Redis and reaches the database, exhausting it. Solutions are parameter validation to reject illegal IDs, caching empty results with short TTLs, and employing a Bloom filter to pre‑check possible existence.

08 Cache Breakdown (Hot Key Expiration)

Breakdown occurs when a single hot key expires, causing a flood of requests for that key to hit the database simultaneously. Example: a superstar product with key product:1001 suddenly expires; all users then query the database for the same item. Mitigations include using a distributed lock so only one request rebuilds the cache, applying logical expiration instead of physical for hot keys, asynchronous background refresh, and combining local cache with Redis.

09 Distinguishing the Three Issues

Summary mnemonic: Avalanche = many keys expire together; Penetration = query non‑existent data; Breakdown = one hot key expires. Corresponding solutions: random TTL / hot‑key no‑expire / rate limiting for avalanche; parameter check / empty‑value cache / Bloom filter for penetration; distributed lock / logical expiration / async refresh for breakdown.

10 How to Answer an Exam Question

When asked to propose optimizations for a high‑traffic e‑commerce system suffering from cache loss, the author suggests: use Redis for read‑heavy data, protect hot‑key expiration with distributed locks or logical expiration, add random jitter to TTLs, cache empty results or use Bloom filters for invalid IDs, and add rate limiting or circuit breaking at the gateway or service layer.

11 Visual Diagram

A simple request flow diagram is drawn: User → Application Service → Redis Cache → Database, with annotations for the three cache problems and their respective solutions.

12 Knowledge Checklist

Key takeaways: cache moves hot data closer to the user; Redis is an in‑memory data‑structure server; String, Hash, List, Set, ZSet types; Avalanche = many keys expire; Penetration = query missing data; Breakdown = hot key expires; mitigation strategies correspond to each problem.

13 Self‑Test Questions

What problem does cache primarily solve?

List Redis's five common data types.

Define cache avalanche, penetration, and breakdown.

Which cache issue is triggered by querying a non‑existent product ID?

Which issue occurs when a hot product's cache suddenly expires?

Provide typical solutions for each of the three cache problems.

If you can answer these in your own words, the cache knowledge is considered mastered.

Final Thoughts

Cache is not just "add Redis and you're done"; it solves repeated database reads for hot data but introduces its own failure modes that must be deliberately designed for, including proper expiration strategies, handling the three cache problems, protecting the database, and ensuring eventual data consistency.