Database and Cache Dual-Write Consistency: Common Solutions and Pitfalls

Introduction

Data consistency between a database and a cache (e.g., Redis) is a language‑agnostic issue that becomes especially severe under high concurrency. The probability of encountering this problem in interviews or real work is high, making it essential to discuss common solutions and their pitfalls.

1. Common Solution

Typically, caching is used to improve query performance. The usual workflow is:

Check the cache; if data exists, return it.

If the cache misses, query the database.

If the database returns data, store it in the cache and return it.

If the database also has no data, return empty.

This pattern seems straightforward, but it overlooks a critical detail: when a database row is updated after being cached, the cache must be updated as well.

Failing to update the cache leads to stale data being served, which is unacceptable.

2. Write Cache First, Then Write Database

Some developers consider updating the cache directly during a write operation. However, if the cache is written first and the subsequent database write fails (e.g., due to a network error), the cache contains data that does not exist in the database, resulting in "dirty" cache data.

In high‑concurrency scenarios, this can cause severe consistency problems, so this approach is generally discouraged.

3. Write Database First, Then Write Cache

This approach avoids the "dirty cache" issue by writing to the database before updating the cache. Yet it introduces new problems:

3.1 Cache Write Failure

If the cache write fails after the database write succeeds, the database holds the new data while the cache still holds the old data, leading to inconsistency.

3.2 High‑Concurrency Issues

When multiple write requests operate concurrently, the following sequence can occur:

Request A writes to the database, then stalls before writing to the cache.

Request B writes to the database and successfully updates the cache.

Request A resumes and overwrites the cache with the old value.

Thus, the cache ends up with stale data while the database has the latest value.

4. Delete Cache First, Then Write Database

Instead of updating the cache, this strategy deletes the cache entry before writing to the database. However, it still suffers from consistency problems in concurrent scenarios.

4.1 High‑Concurrency Issue

Consider a read request C and a write request D arriving simultaneously:

D deletes the cache and stalls before writing to the database.

C reads the cache (miss), then reads the database and obtains the old value, which it writes back to the cache.

D finally writes the new value to the database.

The cache now holds the old value, causing inconsistency.

4.2 Cache Double Delete

To mitigate this, the cache is deleted twice: once before the database write and once after, with a short time interval between deletions. This reduces the window where stale data could be written back to the cache.

5. Write Database First, Then Delete Cache

This approach is recommended as it minimizes the chance of inconsistency. In most cases, the write to the database takes longer than a read, so the cache is usually still valid when the delete occurs.

Edge cases exist (e.g., cache expiration coinciding with a read), but their probability is very low.

6. What to Do When Cache Deletion Fails?

If cache deletion fails after a successful database write, a retry mechanism is needed. Options include:

Synchronous retry (e.g., up to 3 attempts) – may impact performance under high load.

Asynchronous retry using a separate thread, thread pool, retry table, or message queue.

Asynchronous retries are preferred for high‑throughput systems.

7. Scheduled Tasks

Failed cache deletions can be recorded in a retry table and retried later by a scheduled task. A typical strategy retries up to 5 times, updating a retry count each attempt. If all retries fail, the record is marked for manual handling. Elastic‑Job is suggested for its sharding capabilities.

8. Message Queue (MQ)

MQ can also handle cache‑deletion retries. When a cache deletion fails, a message is sent to the MQ. The consumer retries deletion up to 5 times; if still unsuccessful, the message goes to a dead‑letter queue. RocketMQ is recommended for its built‑in retry and dead‑letter support.

9. Binlog Listening

Another elegant solution is to listen to the database binlog (e.g., using Canal). After a successful database write, the binlog subscriber deletes the corresponding cache entry. If deletion fails, the same retry mechanisms (scheduled task or MQ) can be applied.

Overall, the most reliable strategy is to write to the database first, then delete the cache with a double‑delete and retry mechanism, optionally leveraging MQ or binlog listeners for asynchronous handling.