Mastering Cache Consistency: Strategies to Keep Redis and MySQL in Sync

Using cache can dramatically improve system throughput and stability, but it introduces consistency challenges between the cache (typically Redis) and the database (MySQL). The article examines why strong consistency is impractical in high‑traffic scenarios and why eventual consistency with a minimal time window is the realistic goal.

1. Why Cache Matters

Cache trades space for time, using faster storage (e.g., in‑memory Redis) to accelerate read operations. Local memory (L1/L2 cache) can further reduce latency, but its capacity is limited, so only the hottest keys are stored locally.

2. Consistency Challenges with Cache‑Aside

Data resides simultaneously in Redis and MySQL. When Redis is not updated promptly after a DB change, inconsistency appears. Because there is no transactional guarantee between MySQL and Redis, a window of inconsistency always exists, especially during write bursts.

3. Four Cache‑Update Strategies

Update DB then update cache – risky if cache update fails after DB commit.

Update DB then delete cache – preferred for read‑heavy workloads; the window is limited to the time between DB commit and cache deletion.

Update cache then update DB – can produce stale or wrong data if DB update fails.

Delete cache then update DB – avoids stale cache but still vulnerable to race conditions in read‑write concurrency.

Code examples illustrate each approach, e.g.,

data = queryDataRedis(key);
if (data == null) {
    data = queryDataMySQL(key); // cache miss
    if (data != null) {
        updateRedis(key, data);
    }
}

4. Problems with Each Strategy

Updating cache after DB can lead to out‑of‑order writes, causing the cache to reflect an older value. Deleting cache before DB update can still produce inconsistency when a read occurs between deletion and DB commit. Updating cache before DB is especially dangerous because a DB failure leaves the cache with incorrect data.

5. Mitigation Techniques

Delayed double delete : after DB update, delete the cache, wait a short configurable time N , then delete again to cover race conditions.

Cache expiration : set a short TTL (e.g., 1 minute) so that even if a delete fails, the stale entry expires quickly.

Message queue (MQ) reliability : send cache‑invalidating messages via MQ (e.g., RocketMQ transactional messages) to ensure eventual deletion despite service restarts.

Binlog subscription : listen to MySQL binlog (using tools like Canal) to detect changes and trigger cache updates centrally.

6. Handling Multiple Keys and Services

When a single DB record maps to multiple cache keys (e.g., user profile, leaderboard, daily stats), each key must be refreshed or invalidated. Failure of any step can leave parts of the cache inconsistent. A common solution is to publish a single MQ event that a dedicated cache‑maintenance service consumes, updating all related keys atomically.

7. Summary and Recommendations

For most internet services, the recommended strategy is:

Read‑heavy, write‑light: Update DB then delete cache .

Read‑write balanced or write‑heavy: Update DB then update cache , with safeguards such as double delete or MQ‑driven retries.

Ultimately, achieving strong consistency between cache and DB is infeasible without sacrificing performance; the goal is to keep the inconsistency window as short as possible (often <1 ms in LAN environments) and to rely on eventual consistency mechanisms.