Mastering Cache Update Strategies: When to Delete, Update, or Delay

In high‑traffic web systems, caching is essential for performance, but updating cached data consistently with the database is challenging. This article explores three typical cache‑update strategies, evaluates their disadvantages, and proposes practical enhancements.

1. Update Database Then Update Cache

This approach is widely criticized because concurrent updates can cause race conditions: two threads may write to the database in different orders, leading the later thread to overwrite the cache with stale data. Additionally, for write‑heavy workloads or when cache values require expensive computation, repeatedly updating the cache wastes resources.

2. Delete Cache Then Update Database

When a write occurs, the cache is removed before the database update. If a read request arrives between the delete and the database commit, it may read stale data from the database and repopulate the cache with outdated information, resulting in permanent inconsistency unless the cache has an expiration time.

Solution: Delayed Double‑Delete

public void write(String key, Object data) {
    redis.delKey(key);
    db.updateData(data);
    Thread.sleep(1000); // configurable based on business latency
    redis.delKey(key);
}

The first delete removes the old entry, the database is updated, then after a short pause (typically the estimated read‑operation latency plus a few hundred milliseconds) the cache is deleted again to clear any stale data written by concurrent reads.

3. Update Database Then Delete Cache

This pattern, known as the Cache‑Aside pattern, writes to the database first and invalidates the cache afterward. It avoids the race condition of the first strategy but still suffers if the second delete fails, leaving stale data in the cache.

When using MySQL master‑slave replication, the same issue appears: after the master write, a read may hit a replica that has not yet synchronized, causing the replica’s stale value to be cached.

Improved Approaches for Delete Failures

Asynchronous Retry via Message Queue : After a failed cache deletion, the key is sent to a message queue. A separate consumer repeatedly attempts deletion until it succeeds.

Binlog Subscription : A program subscribes to MySQL binlog (e.g., using Canal), extracts affected keys, and triggers cache deletion. If deletion fails, the key is re‑queued for retry.

Both methods can be made asynchronous to avoid blocking the original write request, thereby preserving throughput.

Additional Considerations

Setting a TTL on cache entries provides a safety net, but the double‑delete strategy remains essential for strong consistency. The pause duration should be based on the observed read‑operation latency plus a buffer (typically a few hundred milliseconds). In environments with high write concurrency, combining TTL, delayed double‑delete, and asynchronous retry yields the most reliable consistency.

References:

Cache‑Aside pattern: https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside

Facebook’s Memcache scaling paper: https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf