Mastering Cache Strategies: Avoid Pitfalls and Ensure Data Consistency

Common Concepts

Cache hit: data retrieved from cache without hitting the source. Cache miss: data not in cache, fetched from the source and stored in cache. Storage cost: time and space needed to store data when a miss occurs. Expiration: cached data becomes stale after the source changes. Cache pollution: low‑frequency data occupies cache space, pushing out hot data. Eviction strategies include LRU, LFU, SIZE, FIFO.

Cache Access Scenarios

Three typical problems when using cache:

Cache Penetration

Phenomenon: requests for non‑existent data bypass cache and hit the database, causing overload.

Solutions: use a Bloom filter to filter invalid keys, cache empty objects with a short TTL, validate request parameters.

Cache Breakdown (Stampede)

Phenomenon: a hot key expires, leading to a surge of requests directly to the database.

Solutions: employ a mutex lock so only one request repopulates the cache, or keep the cache "never expires" and refresh asynchronously.

Cache Avalanche

Phenomenon: many keys expire at the same time, flooding the database.

Solutions: add a random offset (1‑5 minutes) to each key’s TTL, use a mutex lock to serialize repopulation.

Data Update Scenarios

When data is updated, both the cache and the database must stay consistent. Common patterns:

Cache‑Aside Pattern

Read flow: try cache → if miss, read from DB and write to cache. Write flow: update the database first, then invalidate (delete) the cache entry.

Invalidating instead of updating avoids dirty data caused by concurrent writes.

cache.delKey(key);
 db.update(data);
 Thread.sleep(xxx);
 cache.delKey(key);

Write‑Through / Read‑Through

Cache acts as the primary store. Writes go through the cache, which synchronously updates the database; reads can be served directly from the cache.

Write‑Behind (Write‑Back)

Writes update the cache first, then an asynchronous task persists the change to the database, improving latency but risking inconsistency if the async write fails.

Consistency Challenges

Two main sources of inconsistency:

Logical failures: concurrent timing issues where reads see stale data after a write.

Physical failures: cache operation failures (e.g., delete fails) that leave stale data.

Solutions include delayed double‑delete, asynchronous message‑driven cache invalidation, Binlog subscription for eventual consistency, and queue‑based serialization of write operations.

Practical Tips

Boost cache hit rate by matching data freshness requirements, using appropriate granularity, and choosing suitable eviction policies.

Select an efficient serialization format to reduce latency and payload size.

Consider GC impact for large objects in languages like Java.

Pick the right cache protocol (Redis, Memcached) based on use‑case.

Configure connection pools and establish comprehensive monitoring.

Multi‑Level Cache Design

Typical layers: client/browser cache → CDN edge cache → Nginx reverse‑proxy cache → remote distributed cache (master/slave) → application local cache (in‑process) → database.

Flow: request reaches Nginx; if hit, return. Otherwise query remote cache; if hit, return and optionally back‑fill Nginx. If miss, check local cache; if hit, return and back‑fill upstream caches. If still miss, read from DB, return, and asynchronously populate caches.

Conclusion

Cache is a powerful tool for high‑performance systems, but misuse can increase maintenance cost and complexity. Understanding cache concepts, common pitfalls, update patterns, and consistency solutions is essential for building reliable, scalable architectures.