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

When optimizing a system, data can be classified into three levels based on real‑time requirements: Level 1 (order and payment flow data) is written directly to 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 the risk of data inconsistency between the cache and the database. The article lists four common strategies for handling cache‑database writes and discusses their advantages and drawbacks:

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.

Strategy 1 can cause heavy cache‑update overhead when write traffic is high and read traffic is low. Strategy 2 may lead to stale reads if the cache is not refreshed promptly. Strategy 3 is essentially the same as Strategy 1 and is rarely used. Strategy 4 can produce stale data when a read request hits the cache before the database transaction commits, especially in read‑write‑splitting architectures.

To mitigate these issues, the article recommends the "delayed double‑delete" approach, which deletes the cache twice with a short delay, and points out that MySQL master‑slave replication latency can still cause inconsistencies.

When the cache‑delete step fails after a successful database update (Strategy 2), a message‑queue‑based compensation mechanism can retry the deletion. However, this tightly couples business code with infrastructure. An alternative is to subscribe to MySQL binlog events and update the cache asynchronously, which reduces coupling at the cost of added system complexity.

In summary, each strategy has trade‑offs; the choice depends on the specific business scenario, performance requirements, and tolerance for added system complexity. No single solution fits all cases.