Cache Consistency Strategies Between MySQL and Redis

MySQL is a persistent database that ensures data reliability, while Redis serves as an in‑memory cache to improve access performance.

Cache inconsistency typically arises when data changes, because updates to the database and cache are performed on separate systems, leading to timing gaps, especially under concurrent read/write scenarios.

The article outlines four main cache‑update design methods:

1. Delete cache then update database – Simple but prone to stale data during concurrency; the article shows a step‑by‑step flow where the cache may contain outdated data after the update.

2. Update database then invalidate cache (Cache‑Aside Pattern) – Generally reduces the window of inconsistency, though a brief period of stale reads can still occur; a detailed flow demonstrates how clients interact with the cache and database.

3. Read/Write‑Through Pattern – The application writes only to the cache, which synchronously updates the database; reads are served from the cache, and cache misses trigger a database fetch that is then cached. This approach minimizes inconsistency but requires cache modification.

4. Write‑Behind (Write‑Back) Pattern – The application updates the cache, and the cache asynchronously propagates changes to the database; this yields high read/write performance but sacrifices strong consistency and can lose data if the cache crashes before persisting.

The article concludes that none of these patterns are perfect; designers should choose the method that best fits their business scenario, balancing consistency, performance, and complexity.