Cache Update Strategies: Analysis, Drawbacks, and Improvement Solutions

Cache is widely used for its high concurrency and performance, but updating the cache consistently with the database remains a challenge. This article analyzes three typical update patterns, evaluates their disadvantages, and offers concrete solutions.

1. Update database first, then update cache – This approach can cause stale data when concurrent requests update the cache out of order, and it wastes resources when write‑heavy workloads repeatedly refresh the cache.

2. Delete cache first, then update database – A read request may fetch stale data from the database before the write completes, leading to inconsistency. The article recommends a delayed double‑delete strategy, illustrated by the following pseudo‑code:

public void write(String key,Object data){
    redis.delKey(key);
    db.updateData(data);
    Thread.sleep(1000);
    redis.delKey(key);
}

The delay (e.g., 1 second) should be tuned based on the expected read‑operation latency plus a safety margin.

3. Update database first, then delete cache (Cache‑Aside pattern) – While this pattern avoids most race conditions, it can still produce dirty data if the delete operation fails or if read‑write‑splitting causes stale reads. The article suggests adding cache expiration, asynchronous delayed deletion, or retry mechanisms.

For cases where the second delete fails, two robust solutions are presented:

Send the failed key to a message queue and retry deletion until it succeeds.

Subscribe to the database binlog (e.g., using Canal for MySQL), extract the affected keys, and retry deletion via a background worker.

Overall, the article provides a comprehensive summary of existing consistency solutions and practical advice for implementing reliable cache‑update workflows in backend systems.