Mastering Cache: Strategies to Boost Performance and Avoid Common Pitfalls

1) Benefits and Cost Analysis

Caching accelerates read/write operations because it resides in memory, and it reduces backend load by offloading frequent or complex queries (e.g., heavy MySQL joins) from the storage layer.

Costs include potential data inconsistency due to update windows, increased code‑maintenance effort for handling both cache and storage logic, and higher operational overhead (e.g., managing a Redis cluster).

Typical use cases are:

Expensive computations such as large join or aggregation queries.

Speeding up request responses; even simple queries like SELECT * FROM table WHERE id=? can benefit from Redis handling tens of thousands of ops per second.

2) Cache Update Strategies

Because cached data can become stale, several update strategies are employed:

LRU/LFU/FIFO eviction : Used when cache memory reaches its limit (e.g., Redis maxmemory-policy).

Timeout eviction : Assign an expiration time; after expiry the data is fetched from the source and re‑cached. Suitable for data tolerant to short‑term inconsistency.

Active update : Immediately refresh the cache after the source data changes, often via a message queue.

For low‑consistency workloads, configure a max‑memory policy; for high‑consistency workloads, combine timeout eviction with active updates.

3) Cache Granularity Control

Choosing the right cache granularity balances three factors: data reusability, memory consumption, and code maintainability. Over‑fine granularity wastes space and bandwidth, while overly coarse granularity reduces cache hit rates.

4) Penetration Optimization

Cache penetration occurs when queries request non‑existent keys, causing both cache and storage misses. It can be caused by bugs or malicious traffic.

Cache empty objects : Store a placeholder for missing keys with a short TTL to prevent repeated storage hits.

Bloom filter : Pre‑filter keys using a Bloom filter; if the filter indicates the key does not exist, the storage layer is never queried.

5) Bottom‑Hole (No‑Bottom) Optimization

Adding more cache nodes does not always improve performance; distributed batch operations can become slower due to increased network round‑trips and connection overhead.

Four batch‑operation approaches in Redis Cluster:

Serial commands : Issue a separate GET for each key (high network cost).

Serial I/O : Group keys by slot, then use MGET or pipeline per node (reduces network trips to the number of nodes).

Parallel I/O : Same as Serial I/O but execute per‑node pipelines concurrently (network cost ≈ O(1), higher code complexity).

Hash‑tag : Force related keys onto the same node using Redis hash tags, achieving a single network round‑trip.

6) Avalanche Optimization

A cache avalanche happens when the cache becomes unavailable, causing a sudden surge of traffic to the storage layer and potentially cascading failures.

Prevention measures:

Ensure high availability of the cache layer (e.g., Redis Sentinel or Redis Cluster).

Isolate critical resources with circuit breakers and thread‑pool segregation.

Conduct failure‑drill simulations before production release.

7) Hot‑Key Rebuild Optimization

When a hot key expires, many concurrent threads may try to rebuild it, overwhelming the backend.

Two common solutions:

Mutex lock : Use SETNX (or SET nx ex) to allow only one thread to rebuild; others wait and retry after a short sleep.

Never‑expire (logical expiration) : Keep the key physically permanent but attach a logical TTL; a background thread rebuilds the value when the logical TTL expires.