How to Ensure Cache‑Database Consistency: Patterns and Pitfalls Explained

Introduction

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 common cache consistency problems and how to answer such interview questions.

What is Consistency?

Consistency means data values remain the same across distributed nodes. Three levels are described:

Strong consistency : reads always reflect the latest writes.

Weak consistency : reads may not see the latest write immediately, but will converge within a bounded time.

Eventual consistency : a special case of weak consistency where the system guarantees convergence after some time.

Three Classic Cache Patterns

Cache can improve performance but introduces inconsistency. The three classic patterns are:

Cache‑Aside Pattern

Read‑Through / Write‑Through

Write‑Behind

Cache‑Aside Pattern

Also called “旁路缓存模式”, it tries to minimize cache‑DB inconsistency.

Read flow

1. Read cache; if hit, return data. 2. If miss, read DB, populate cache, and return.

Write flow

1. Update DB first. 2. Delete the related cache entry.

Deleting the cache avoids the “dirty data” problem that occurs when two concurrent writes update the cache in different order.

Read‑Through / Write‑Through

The application interacts with an abstract cache layer. In Read‑Through, a cache miss triggers a DB load and cache population. Write‑Through updates both cache and DB synchronously.

Read‑Through is essentially Cache‑Aside with an extra cache‑provider layer, simplifying code and reducing DB load.

Write‑Behind (Asynchronous Write)

Similar to Read‑Through/Write‑Through but writes to the DB asynchronously in batches. This improves write‑heavy scenarios but weakens consistency.

Use cases include MySQL InnoDB buffer pool.

Should We Delete or Update Cache on Write?

Deleting the cache prevents stale data when concurrent writes occur. Updating the cache can waste CPU if the value requires complex computation and may still lead to inconsistency in write‑heavy workloads.

Which Operation Comes First in Double‑Write?

In Cache‑Aside, the DB is updated before the cache is deleted. Doing the opposite can cause the cache to hold old data while the DB holds new data.

Can We Achieve Strong Consistency Between Cache and DB?

Absolute consistency is impossible due to the CAP theorem; caches belong to the AP side. Strong consistency can be approximated with techniques such as locking, optimistic CAS, or distributed transactions, but they add complexity.

Three Practical Solutions to Keep Cache and DB Consistent

Delayed Double Delete

1. Delete cache. 2. Update DB. 3. Sleep (e.g., 1 s) and delete cache again.

The sleep time should cover the longest read‑business latency plus a safety margin.

Cache‑Delete Retry Mechanism

If cache deletion fails, push the key to a message queue and retry until successful.

Asynchronous Deletion via Binlog

Capture MySQL binlog (e.g., using Alibaba Canal), send update events to a MQ, and delete the corresponding cache entry asynchronously.

Conclusion

While perfect consistency is unattainable, combining the above patterns and safeguards can provide weak or eventual consistency that satisfies most business requirements.