Ensuring Data Consistency Between Cache and Database: Strategies and Trade‑offs

The author, a senior architect, introduces the challenge of ensuring data consistency between cache layers and the database during double‑write operations.

Data is classified into three levels based on real‑time requirements: Level 1 (order and payment flow data) is accessed directly from the database without caching; Level 2 (user‑related data) is cached in Redis; Level 3 (payment configuration) is cached in local memory.

Using any cache introduces synchronization issues, leading to inconsistencies when the database is updated but the cache is not.

Four basic strategies are listed:

Update the database first, then update the cache.

Update the database first, then delete the cache.

Update the cache first, then update the database.

Delete the cache first, then update the database.

The article analyzes each approach, highlighting drawbacks such as high cost of updating cache after database writes, stale data, and failure scenarios.

For the “delete‑then‑update database” case, a delayed double‑delete technique is suggested to mitigate race conditions.

When deleting the cache after a database update fails, a message‑queue‑based compensation mechanism is proposed: the failed key is sent to a queue and retried later.

To avoid heavy code intrusion, the author recommends subscribing to MySQL binlog events and updating the cache based on those logs, though this adds system complexity.

In summary, each solution has trade‑offs; the choice depends on business characteristics, and there is no one‑size‑fits‑all method for cache‑database consistency.

Additional promotional content and links are included at the end of the original article.