How Long Should the Delay Be in Delayed Double Delete? A Deep Dive into Cache Consistency

1. What Is Consistency?

Consistency means keeping data identical across multiple nodes; in distributed systems it ensures that the values stored in different locations are the same. For example, when user information is cached in Redis and also stored in a database, both must stay synchronized.

Strong consistency : reads always return the most recent write, providing the best user experience but often at a performance cost.

Weak consistency : after a write, the system does not guarantee immediate visibility; it only promises eventual convergence within a bounded time (e.g., seconds).

Eventual consistency : a special case of weak consistency where the system guarantees that, given enough time, all replicas will converge to the same state. This model is widely adopted in large‑scale distributed systems.

2. Cache Usage and Patterns

2.1 Cache‑Aside

Read flow: first check the cache; if it hits, return the data directly. If it misses, read from the database, store the result in the cache, and return the response.

Write flow: update the database first, then delete the related cache entry.

2.2 Read/Write‑Through

In this mode the cache acts as the primary data store. All reads and writes go through a cache abstraction layer.

Read‑Through flow: attempt to read from the cache; on miss, load from the database, write the result into the cache, and return it.

Write‑Through flow: on a write request, the cache layer updates both the cache and the underlying database synchronously.

2.3 Write‑Behind (Asynchronous Cache Write)

Write‑Behind also uses a cache provider, but unlike Write‑Through it updates the cache first and defers the database write, batching updates asynchronously. This improves write‑heavy workloads but weakens consistency, so it should be used cautiously for data that requires strong consistency.

3. Delete vs. Update Cache

When updating data, deleting the cache entry instead of updating it avoids stale‑data scenarios. An example shows two concurrent writes where updating the cache leads to dirty data, while deleting the cache prevents the inconsistency.

4. Order of Operations in Double Write

In the Cache‑Aside pattern, the database is updated first, then the cache is deleted. This order prevents a race condition where a read could fetch stale data from the cache before the database update is visible.

5. Can DB and Cache Be Strongly Consistent?

Absolute strong consistency between a database and a cache is impractical. Techniques such as locking, CAS/optimistic locks, or distributed transactions (3PC, TCC) can reduce inconsistency, but they add complexity and overhead. Because caches belong to the AP side of the CAP theorem, they are best suited for scenarios that tolerate eventual or weak consistency.

6. Delayed Double Delete

This technique aims to eliminate stale cache entries after a database update:

Delete the cache entry before updating the database.

Perform the database update.

Sleep for a period equal to the average read‑operation latency plus a few hundred milliseconds.

Delete the cache entry again to remove any dirty data that might have been written during the pause.

The pause duration is typically “read‑latency + a few hundred milliseconds”, ensuring that most concurrent reads finish before the second deletion.

7. Alternative Solutions

7.1 Cache‑Delete Retry Mechanism

If the second deletion fails, the key can be placed into a message queue for retry. A consumer reads the queue and attempts to delete the key repeatedly until successful.

7.2 Binlog‑Based Asynchronous Deletion

By capturing MySQL binlog events (e.g., using Alibaba Canal) and sending them to a message queue, a consumer can process update events and delete the corresponding cache keys, guaranteeing eventual consistency without modifying business code.