Cache Usage Techniques and Design Solutions: Benefits, Costs, Update Strategies, Granularity, and Common Optimizations

Cache can effectively accelerate application read/write speed and reduce backend load, making it essential for everyday development. The article introduces cache usage techniques and design schemes, covering benefit‑cost analysis, update‑strategy selection, granularity control, penetration mitigation, empty‑hole handling, avalanche prevention, and hot‑key reconstruction.

1) Benefit‑Cost Analysis of Cache

The left diagram shows a client directly calling the storage layer, while the right diagram adds a typical cache‑plus‑storage architecture.

Benefits:

Accelerated read/write: caches are usually in‑memory, offering faster access than storage systems such as MySQL.

Reduced backend load: caches lower the number of requests and complex computations hitting the database.

Costs:

Data inconsistency: a time window of inconsistency exists between cache and storage, depending on the update strategy.

Code maintenance: developers must handle both cache and storage logic, increasing code complexity.

Operational overhead: e.g., deploying a Redis Cluster adds operational cost.

Typical cache usage scenarios:

Expensive complex calculations (e.g., heavy MySQL joins or aggregations) that would otherwise overload the database.

Accelerating request response: even simple queries like select * from table where id= can benefit from Redis, which can handle tens of thousands of operations per second.

2) Cache Update Strategies

Because cached data may become stale, several update strategies are introduced:

LRU/LFU/FIFO eviction : used when cache usage exceeds a predefined limit (e.g., Redis maxmemory-policy ).

Timeout eviction : set an expiration time; after expiry the cache entry is removed and refreshed from the source.

Active update : immediately refresh the cache after the underlying data changes, often via a message system.

Two recommendations:

Low‑consistency workloads: configure max‑memory and an eviction policy.

High‑consistency workloads: combine timeout eviction with active updates.

3) Cache Granularity Control

Improper granularity can waste space, bandwidth, and reduce code reusability. Choose granularity based on data generality, space consumption, and maintenance cost. A common stack is Redis for cache and MySQL for storage.

4) Penetration Optimization

Cache penetration occurs when queries for non‑existent data miss both cache and storage. Solutions include:

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

Bloom filter interception : maintain a Bloom filter of existing keys to filter out impossible queries before hitting storage.

5) Empty‑Hole Optimization

Adding many cache nodes does not always improve performance; distributed batch operations can become slower. Optimizations focus on reducing network round‑trips, using pipelines, parallel I/O, or Redis hash‑tag to co‑locate keys.

6) Avalanche Optimization

When the cache becomes unavailable, all traffic falls back to storage, potentially causing a cascade failure. Preventive measures include high‑availability cache setups (Redis Sentinel/Cluster), backend rate‑limiting and degradation, and pre‑deployment failure drills.

7) Hot‑Key Reconstruction Optimization

Hot keys that expire simultaneously can cause a thundering‑herd problem. Solutions:

Mutex lock : use Redis SETNX to ensure only one thread rebuilds the cache while others wait.

Never‑expire + logical expiration : keep the key permanently in cache but refresh its value asynchronously based on a logical TTL.

Both approaches aim to reduce rebuild frequency, maintain data consistency as much as possible, and avoid additional risks.