Why Delayed Double Delete Fails to Ensure Cache Consistency Under High Concurrency

Problem Overview

Many developers use the standard "delete cache → update MySQL → delayed second delete" sequence to keep Redis and MySQL consistent. The second delete is meant to clear a stale cache entry that might be written back by a read request occurring between the first delete and the database update.

Delay Time Hard to Set

The sleep interval N ms is critical. If N is too short, the second delete may run before a read request writes the stale value back, making the delete ineffective. If N is too long, all reads during the sleep see the stale cache, causing prolonged inconsistency. Typical guidance—set N to request latency plus a few hundred milliseconds—fails under high load because latency can swing from 50 ms to 500 ms, making any fixed value either wasteful or insufficient. Moreover, the delay is hard‑coded, so any change in database performance, network stability, or cluster size forces a code change.

Thread Sleep Blocks Business

Implementing the delay with Thread.sleep(500) blocks the business thread. In a high‑concurrency scenario, each write request holds a thread idle for the sleep duration. With 1 000 writes per second, 1 000 threads become blocked, quickly exhausting the thread pool and causing queuing or time‑outs.

Second Delete May Fail

The second Redis delete depends on network reliability. Network jitter, temporary Redis unavailability, or time‑outs can cause the delete to fail. Handling failures requires retries, back‑off strategies, and additional error‑handling code, which adds complexity and still cannot guarantee eventual consistency.

Concurrent Writes Issue

Delayed double delete assumes a single write and a single read. When two writes A and B arrive concurrently, the ordering can break the guarantee. If B arrives later but its final value Y should win, the database may still contain X from A, and the cache will reflect the wrong state. This is a database‑level write‑order problem that delayed double delete cannot solve.

Recommended Approach

Use a cache‑aside strategy: read from cache first, fall back to the database if the cache misses, and write the result back to the cache. Crucially, update the database first and then delete the cache entry. This reduces the window where a read can hit stale data to microseconds, far smaller than the window created by deleting first.

Cache Aside (update DB then delete cache) – suitable for most scenarios.

Cache Aside + TTL – adds a short time‑to‑live as a safety net for brief inconsistencies.

Canal listening to binlog + MQ async update – for high‑consistency requirements.

Distributed lock to serialize write requests – for severe write‑conflict cases.

Delayed double delete can still work in low‑concurrency, low‑consistency‑requirement environments, but once traffic grows, each of its assumptions is likely to be violated, making the more robust cache‑aside patterns a better choice.