Cache Consistency Challenges and Practical Strategies for Database‑Redis Integration

In real‑world business scenarios, core data such as orders, members, and payments are persisted in relational databases (e.g., MySQL) for transactional guarantees, but the databases often cannot handle the high QPS demanded by large‑scale traffic, leading developers to introduce a fast cache layer (typically Redis) to serve the majority of read requests.

Cache significance : caching trades space for time by storing frequently accessed, relatively static data in a high‑speed storage medium, thereby improving overall read performance.

Consistency challenge : when data exists simultaneously in Redis and MySQL, any delay between updating the database and synchronizing the cache creates a window of inconsistency. Because there is no transactional guarantee across the two systems, writes may succeed in MySQL while the corresponding cache update fails, or the order of operations may cause stale values to be read.

Four common write‑path strategies are examined:

Update database then update cache – can cause temporary stale reads during the short interval before the cache is refreshed.

Update database then delete cache – generally safe; the stale‑read window is minimal (≈1 ms) and often negligible.

Update cache then update database – risky because if the database update fails, the cache holds incorrect data.

Delete cache then update database – may lead to read‑write race conditions where a read request repopulates the cache with old data before the database commit.

Sample code for the typical read‑through pattern:

data = queryDataRedis(key);
if (data == null) {
    data = queryDataMySQL(key); // cache miss, query DB
    if (data != null) {
        updateRedis(key, data); // populate cache after DB read
    }
}

Examples of problematic write sequences:

updateMySQL();
updateRedis(key, data);

and

updateRedis(key, data); // update cache first
updateMySQL(); // then update DB

To mitigate these issues, the article recommends the "post‑update delete" strategy (update DB then delete cache) for read‑heavy workloads, and the "update‑then‑update" strategy for write‑heavy scenarios. It also suggests using short cache TTLs (e.g., 1 minute) to bound the maximum inconsistency window, employing reliable message queues (at‑least‑once delivery) to asynchronously invalidate caches, and leveraging MySQL binlog listeners (e.g., Canal) to react to actual data changes and keep caches in sync.

For complex cases where a single DB record maps to multiple cache keys, the article proposes publishing cache‑invalidating or updating events to a message bus, allowing dedicated services to handle all related keys consistently.

Overall, the recommended practice is to aim for eventual consistency: ensure that any cache entry that becomes stale is either quickly evicted or refreshed, using a combination of expiration, delayed double deletion, MQ‑driven invalidation, and binlog‑based synchronization.