Cache Strategies: Consistency Issues, Penetration, Avalanche and Mitigation Techniques

In real‑world development, frequent disk reads and database queries can become performance bottlenecks, so a cache layer between the application and MySQL is commonly added.

Cache‑aside (read‑through) is the most widely used pattern: on a cache hit the data is returned from the cache; on a miss the database is queried and the result is stored in the cache; on a write the cache entry is invalidated after the database update.

Cache Aside, Read Through, Write Through, Write Behind Caching

Although simple, cache‑aside can produce stale data when a read misses, a write occurs, and the subsequent read repopulates the cache with outdated information.

Read‑through delegates all reads to the cache, which fetches from the database on a miss and updates itself automatically, improving code readability but requiring custom provider plugins.

Write‑through updates the cache first and then the database, while write‑behind writes only to the cache and synchronises to the database asynchronously, reducing DB load but risking data loss if the cache node crashes.

Cache penetration occurs when many requests for non‑existent keys bypass the cache and hammer the database; common mitigations include caching null results and using a Bloom filter to pre‑filter invalid keys.

Cache avalanche happens when many cached items expire simultaneously or a cache server restarts, causing a sudden surge of DB traffic; mitigation strategies include distributed locking during cache rebuild, pre‑warming caches, staggering TTLs, employing master‑slave‑sentinel or Redis‑Cluster architectures, and adding a local Ehcache layer with Hystrix for rate‑limiting and fallback.

For further reading, see the NSDI13 paper on cache consistency (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf).