How to Ensure Cache‑Database Consistency: Patterns, Pitfalls, and Solutions

Preface

In April a friend interviewed at Meituan and was asked how to guarantee consistency between Redis and MySQL in a double‑write scenario. This article explores how to answer that question.

Understanding Consistency

Consistency means keeping data identical across nodes in a distributed system.

Strong consistency : Reads always return the most recent write, offering good user experience but often hurting performance.

Weak consistency : The system does not guarantee immediate visibility of writes; it aims to become consistent after a certain time (e.g., seconds).

Eventual consistency : A special case of weak consistency where the system guarantees that data will become consistent after some time.

Three Classic Cache Patterns

Caching improves performance and reduces database load, but can cause data inconsistency. The three classic patterns are:

Cache‑Aside Pattern

Read‑Through / Write‑Through

Write‑Behind

Cache‑Aside Pattern

Also called the bypass cache pattern, it aims to minimize cache‑database inconsistency.

Read Flow

The read process is:

Read from cache; if hit, return the data.

If miss, read from the database, populate the cache, and return the response.

Write Flow

When updating, first update the database, then delete the corresponding cache entry.

Read‑Through / Write‑Through

In this pattern the cache acts as the primary data store, and applications interact with an abstract cache layer.

Read‑Through

Read from cache; if miss, load from the database, write to cache, and return.

Write‑Through

Write requests are handled by the cache abstraction layer, which updates both the cache and the underlying data source synchronously.

Write‑Behind (Asynchronous Cache Write)

Similar to Read‑Through/Write‑Through but updates the cache only and writes to the database asynchronously in batches, which reduces write latency but weakens consistency.

Should We Delete or Update the Cache on Writes?

Using Cache‑Aside, deleting the cache after a database update avoids stale data caused by concurrent writes that might otherwise overwrite each other.

Updating the cache can waste performance if the value requires expensive computation.

In write‑heavy, read‑light scenarios, updating may be unnecessary overhead.

In Double‑Write Scenarios, Do We Operate the Database First or the Cache First?

Operating the database first and then deleting the cache prevents the cache from holding stale data, as illustrated by a sequence where a concurrent read could otherwise cache old data.

Can We Achieve Strong Consistency Between Database and Cache?

Absolute strong consistency is impossible due to the CAP theorem; caches belong to the AP side, so strict consistency is unsuitable for cache‑enabled systems.

CAP theorem states that a distributed system can only simultaneously provide two of the three guarantees: Consistency, Availability, and Partition tolerance.

However, weak or eventual consistency can be ensured with proper techniques.

Three Solutions to Ensure Consistency

Delayed Double Delete

Delete the cache, update the database, then after a short pause (e.g., 1 second) delete the cache again to cover race conditions.

Cache Delete Retry Mechanism

If the second delete fails, place the key in a message queue and retry deletion until it succeeds.

Asynchronous Deletion via Binlog

Capture MySQL binlog changes (e.g., using Alibaba Canal), push them to a message queue, and upon acknowledgment delete the related cache key, ensuring eventual consistency.