How to Keep Redis and MySQL Consistent: 4 Proven Strategies for Interviews

In 2019 and 2020 the author faced interview questions about guaranteeing data consistency between Redis and MySQL, prompting a discussion of common caching scenarios.

What is a cache?

A cache stores results from slower storage in faster memory to improve query efficiency. In database systems, Redis serves as a cheap, high‑performance cache for the more reliable but slower MySQL.

Why use a cache?

MySQL provides full ACID guarantees but can become a bottleneck under high read traffic. Because 80 % of requests target 20 % of hot data, adding a cache layer reduces load, improves throughput, and increases system robustness. Cache hits serve data from Redis; misses fall back to MySQL.

Consistency challenge

When MySQL data changes, stale Redis entries may appear. Interviewers usually expect an eventual‑consistency solution rather than strong consistency, which would negate the benefits of caching.

Four practical solutions

Solution 1: Let entries expire

Set an expiration time on Redis keys and do nothing when MySQL updates. The cache becomes stale until it expires.

Pros: Simple, low development cost, uses native Redis commands.

Cons: Stale data persists for the expiration window; may cause many dirty reads under heavy traffic.

Solution 2: Delete then repopulate

In addition to expiration, attempt to delete the Redis key when MySQL updates. If deletion succeeds, the next read fetches fresh data from MySQL and rewrites the cache.

Pros: Reduces inconsistency window, modest implementation effort.

Cons: Deletion failures revert to solution 1; double connections to MySQL and Redis increase resource usage.

Solution 3: Active update via message queue

Publish MySQL update events to a message queue; a consumer service asynchronously updates Redis, ensuring at‑least‑once delivery.

Pros: Decouples write path, reliable delivery, improves consistency.

Cons: Possible ordering issues, added infrastructure cost, extra client connections.

Solution 4: Binlog subscription (log‑based sync)

Run a sync service that subscribes to MySQL binlog, parses changes, and updates Redis. This approach fully decouples business logic.

Pros: Low latency under moderate load, no ordering problems, strong reliability.

Cons: Requires building a binlog sync service, higher operational cost, risk of stale cache if the service fails.

Choosing a strategy

Assess product latency requirements; if strict, avoid caching.

For typical read‑heavy, write‑light scenarios, solution 1 is often sufficient.

When faster freshness is needed, adopt solution 2 while keeping deletion non‑critical.

For high‑latency‑sensitive workloads, prefer solution 4 (or solution 3) to achieve near‑real‑time sync.

Interview tip

Present the four solutions, discuss their trade‑offs, and guide the interviewer through scenario‑based selection to demonstrate depth of knowledge.