Cache Consistency Strategies Between MySQL and Redis

1. How Cache Inconsistency Happens

When data does not change, cache inconsistency does not occur; however, once data is modified, the need to update both the database and the cache introduces a time gap because they are separate systems, leading to possible inconsistency, especially under concurrent read‑write scenarios.

2. Cache‑Update Design Methods

Four common patterns are described:

Delete cache then update database – This approach often leaves stale data in the cache during concurrent operations and is generally discouraged.

Update database then invalidate cache (Cache‑Aside) – After updating the database, the cache entry is deleted; subsequent reads repopulate the cache, minimizing the window of inconsistency.

Read/Write‑Through – All writes go to the cache, which synchronously updates the database; reads hit the cache, and cache misses trigger a database read that is then cached.

Write‑Behind (Asynchronous) – Writes are applied only to the cache, which later propagates the changes to the database asynchronously, offering high performance but risking data loss if the cache fails before flushing.

2.1 Delete Cache Then Update Database

The execution flow may be: client 1 deletes cache entry A, client 2 reads cache (miss), fetches from DB and caches it, then client 1 updates DB. The cache ends up holding stale data, so this method is not recommended.

2.2 Update Database Then Invalidate Cache (Cache‑Aside)

The flow can be: client 1 updates DB, client 2 reads cache (hits old data), client 1 invalidates cache, client 3 reads cache (miss), fetches from DB, and updates cache. The inconsistency window is short and usually acceptable.

2.3 Read/Write‑Through Pattern

Clients write to the cache, which synchronously updates the DB; reads hit the cache, and on a miss the cache fetches from the DB and stores the result. This pattern yields near‑zero inconsistency but requires cache modification.

2.4 Write‑Behind Cache Pattern

Clients update the cache, which asynchronously writes the changes to the DB. This provides excellent read/write performance, though it is eventually consistent and can lose data if the cache crashes before flushing.

Summary

All four cache‑update designs have trade‑offs; none is perfect. System designers should choose the pattern that best fits their business scenario rather than striving for an unattainable perfect solution.