Handling Data Consistency Between Redis Cache and Relational Databases

Redis is often used as a distributed cache for hot data that originates from relational databases, which introduces data consistency problems when write operations occur. While read‑only scenarios remain consistent, any modification to the underlying data can cause the cache and the database to diverge.

The read flow is straightforward: a client first queries the cache; if the key exists, the cached value is returned, otherwise the database is queried, the result is stored in the cache, and then returned.

Write operations are more complex and can be categorized into four cases: (1) update cache then update database, (2) update database then update cache, (3) delete cache then update database, and (4) update database then delete cache. In practice, deleting the cache is usually preferred because updating cached data often requires recomputing values from multiple tables.

Two of the five scenarios—deleting the cache before updating the database and updating the database before deleting the cache—are examined in detail. Both can lead to inconsistency under concurrent read/write conditions. For the "delete‑then‑update" case, a typical sequence is: user deletes the cache, then attempts to update the database (which may be delayed), another user reads the cache (now empty) and falls back to the stale database value, resulting in mismatch.

To mitigate this, a delayed double‑delete strategy is proposed: delete the cache, update the database, wait for a short period, and delete the cache again. The sample code is:

redis.del(key);
mysql.update(data);
Thread.sleep(500); // delay depends on business scenario
redis.del(key);

Even with the second delete, if a read occurs before it completes, stale data may still be returned.

The alternative "update‑then‑delete" approach suffers from similar issues: after the database update, the cache deletion may be delayed, allowing other users to read outdated cached data.

In summary, introducing Redis as a distributed cache inevitably brings data inconsistency challenges, especially for write operations. Choosing whether to update or delete the cache first does not fully eliminate the risk; additional mechanisms such as message‑queue‑based retry deletions, or change‑data‑capture tools like Canal to synchronize MySQL changes to the cache, can further improve consistency.