Which Cache Update Strategy Guarantees Consistency? A Deep Dive into DB‑Cache Synchronization

Why Write This Article?

Cache is widely used for high‑concurrency reads, but updating cache after database changes is controversial. This article analyzes three update strategies, their drawbacks, and improvement methods.

Article Structure

Explain cache update strategies

Analyze drawbacks of each

Provide improvement solutions

Main Content

Three strategies are discussed:

Update database then update cache

Delete cache then update database

Update database then delete cache

Strategy 1: Update DB → Update Cache

Problems: thread‑safety issues can cause dirty data when concurrent requests update cache in different order; also inefficient for write‑heavy workloads.

Strategy 2: Delete Cache → Update DB

Can cause inconsistency because a read request may fetch stale data from the database before the write completes. Solution: delayed double‑delete – delete cache, write DB, sleep ~1 s, delete cache again.

Strategy 3: Update DB → Delete Cache

Based on the Cache‑Aside pattern; still vulnerable to race conditions, but probability is low. Mitigations include setting cache TTL or using the delayed double‑delete with asynchronous second delete.

Handling Delete Failures

Two retry mechanisms are proposed: (1) send failed keys to a message queue and retry until success; (2) use MySQL binlog subscription (e.g., Canal) to capture changes and retry deletions.

Conclusion

The article summarizes existing consistency solutions for internet‑scale systems and suggests practical ways to avoid cache‑DB inconsistency.