Cache and Database Consistency: Strategies for Updating Order

Data Inconsistency Pitfall: A "Visual Deception"

Cache and database layers are independent systems; updating them atomically is impossible, which easily leads to data inconsistency. For example, in an e‑commerce scenario, a product price changes from 1000 CNY to 1200 CNY in the database, but the cache still shows the old price, misleading users and harming platform credibility.

Update Strategy Showdown: Pros and Cons of Four Approaches

Update Database First, Then Cache

This seemingly logical method has obvious risks. If 缓存更新失败 occurs, the database is updated while the cache lags behind, similar to a relay race where the second runner fails to receive the baton.

Delete Cache First, Then Update Database

In this approach, the cache is removed before the database update. Under concurrent conditions, problems arise: if thread A deletes the cache, thread B quickly reads the database and repopulates the cache, and then thread A updates the database, the 缓存数据就会“穿越”回旧版本 , creating a chaotic "time‑shift".

Update Database First, Then Delete Cache (Cache‑Aside Pattern)

This is the classic solution. Read operations check the cache first; on a miss, they query the database and refresh the cache. Write operations update the database first, and upon success delete the cache. This 最大程度避免数据不一致 , akin to a well‑choreographed duet where each step is tightly coordinated.

Delayed Double‑Delete Strategy: Adding a "Double Insurance" for Consistency

After updating the database, the cache is 立即删除缓存 , then a short delay is set before deleting the cache again 短暂的延迟，再去删除缓存 . This double‑insurance reduces the risk of inconsistency caused by cache‑deletion failures, though the delay must be tuned to balance success rate and request latency.

Why Delete Cache Instead of Updating? The Wisdom Behind Lazy Loading

Deleting the cache follows the "lazy loading" principle. Cache data may aggregate many underlying tables and be costly to update. Some cache entries are rarely accessed, so removing them and repopulating on the next request is more efficient, similar to the "decluttering" concept.

Multi‑Level Cache Synchronization Challenge: The "Coordinated Dance" in Complex Scenarios

Multi‑level caches are common in complex systems, but ensuring consistency is difficult. For use‑cases with relaxed consistency requirements (e.g., news feeds, user comments), a typical solution is to broadcast invalidation messages via a 消息队列广播通知 after the database update, using transactional message queues to coordinate cache eviction.

Conclusion: Dancing Elegantly in the Data World

The order of cache and database updates is a carefully choreographed dance with no one‑size‑fits‑all solution. Developers must choose strategies based on business scenarios, possibly combining version numbers or timestamps to achieve eventual consistency. Hopefully this article equips you with the insight to handle the "soul‑searching" question of cache‑database updates and avoid falling into inconsistency pitfalls.