Ensuring Consistency Between Cache and Database: Patterns and Strategies

Introduction

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

Consistency Basics

Consistency means data remains the same across nodes in a distributed system. It can be classified as strong consistency, weak consistency, and eventual consistency.

Three Classic Cache Patterns

Cache can improve performance but may cause data inconsistency. The three classic patterns are Cache‑Aside, Read‑Through/Write‑Through, and Write‑Behind.

Cache‑Aside Pattern

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

Read Flow

Read from cache; if miss, read from DB, populate cache, return data.

Write Flow

Update DB first, then delete the cache.

Read‑Through / Write‑Through

Cache acts as the primary data store via an abstract cache layer.

Read‑Through

Read from cache; if miss, load from DB, write to cache, return.

Read‑Through adds a cache‑provider layer on top of Cache‑Aside.

Write‑Through

Writes go through the cache abstraction, updating both cache and DB synchronously.

Write‑Behind (Asynchronous Cache Write)

Similar to Read‑Through/Write‑Through but updates the DB asynchronously in batches.

Suitable for write‑heavy scenarios but weakens consistency.

Should We Delete or Update Cache on Write?

Using Cache‑Aside, deleting the cache avoids stale data that can appear when concurrent writes update the cache in different orders.

Updating cache has drawbacks such as extra computation and wasted performance in write‑heavy workloads.

Which Operation Comes First: DB or Cache?

In Cache‑Aside, the database is updated first, then the cache is deleted, to prevent a race condition where a read could repopulate the cache with stale 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 is rarely needed for cache‑able data.

CAP theorem: In a distributed system, Consistency, Availability, and Partition tolerance cannot all be achieved simultaneously.

Weak or eventual consistency can be ensured with proper techniques.

Three Solutions to Keep Cache and DB Consistent

Cache‑Side Delayed Double Delete

Delete cache, update DB, wait (e.g., 1 s), delete cache again.

The delay should cover read latency plus a safety margin.

Cache Delete Retry Mechanism

If a cache delete fails, retry or push the key to a message queue for later deletion.

Asynchronous Delete via Binlog

Use MySQL binlog (e.g., via Alibaba Canal) to capture updates, send them to a MQ, and delete cache after ACK.