Database and Cache Double-Write Consistency: Common Solutions and Best Practices

Database and cache double‑write consistency is a language‑agnostic issue that becomes severe under high concurrency.

The article first describes the typical cache‑first read flow and the problem when data is updated in the database but the cache becomes stale.

Four common double‑write strategies are presented:

Write cache then write database.

Write database then write cache.

Delete cache then write database.

Write database then delete cache.

Each strategy is analyzed; the cache‑first approach can produce dirty data if the database write fails, while the database‑then‑cache approach can cause stale cache under concurrent writes.

High‑concurrency scenarios are illustrated with request sequences showing how newer data can be overwritten by older data in the cache.

The article recommends the “write database then delete cache” method as the most reliable, though it still may encounter rare inconsistencies.

To mitigate cache‑deletion failures, various retry mechanisms are discussed: synchronous retries, asynchronous retries via thread pools, retry tables with scheduled tasks, message‑queue retries (e.g., RocketMQ), and binlog listeners (e.g., Canal) that delete cache after database changes.

Examples of code snippets are shown using 假数据 , 新数据 , 旧数据 , and 重试机制 to illustrate concepts.

Finally, the article notes that while these solutions improve consistency, they cannot guarantee 100% correctness, and proper monitoring and fallback strategies are essential.