Database Cache Consistency: Strategies and Trade‑offs Using Redis as a MySQL Cache

Background

Cache is a crucial concept in software development; database caching is a scenario that appears in almost every project. Ensuring cache consistency is a frequent interview topic, and the appropriate consistency strategy must be chosen based on specific requirements.

What Is Cache

Cache stores the results of slower storage in faster storage temporarily, effectively creating a high‑speed layer above slower layers.

Why Use Cache

MySQL provides full ACID guarantees but its performance can be limited under high concurrency, leading to instability and latency. According to the principle of locality, 80% of requests hit 20% of hot data, so adding a cache layer greatly improves throughput and robustness in read‑heavy, write‑light scenarios.

Problems

Data in the underlying store may change over time, causing the cache to become stale. The tolerable staleness window depends on business needs, but most applications aim for eventual consistency.

Redis as MySQL Cache

Typical architecture uses MySQL for persistence and Redis as a cache to accelerate reads and protect MySQL. The key question is how to keep Redis synchronized when MySQL data changes.

Solution Overview

Solution 1 – TTL Expiration

Set an expiration time for cache keys and do not update Redis when MySQL changes.

Advantages:

Low development cost and easy implementation.

Low operational overhead and low failure probability.

Disadvantages:

Reliance on expiration time: short TTL causes frequent cache misses, long TTL leads to prolonged inconsistency.

Solution 2 – Write‑Through with TTL Backup

Extend Solution 1 by updating Redis immediately after a successful MySQL write, while still keeping TTL as a fallback.

Advantages:

Reduces update latency compared with Solution 1.

Disadvantages:

If Redis update fails after MySQL succeeds, the system degrades to Solution 1.

In high‑concurrency scenarios the application must maintain connections to both MySQL and Redis, increasing connection pressure.

Solution 3 – Asynchronous Update via Message Queue

Improve Solution 2 by decoupling Redis updates through a message queue (e.g., Kafka). After MySQL writes, a message is sent to the queue; a consumer service asynchronously updates Redis.

Advantages:

Message queue can batch and locally cache messages, alleviating connection pressure.

Achieves logical decoupling between business logic and cache updates.

Queue reliability (e.g., at‑least‑once delivery) improves update guarantee.

Disadvantages:

Does not solve ordering issues: concurrent updates on the same row may be processed out of order, causing inconsistency.

Introduces additional infrastructure and potential duplicate‑consumption risks.

Solution 4 – Binlog Subscription

Deploy a consumer service that acts as a MySQL replica, subscribes to the binary log (binlog), parses change events, and updates Redis accordingly.

Advantages:

Low latency when MySQL load is moderate.

Fully decoupled from business services.

Resolves ordering problems because changes are applied in the exact order they occurred in MySQL.

Disadvantages:

Requires building a dedicated synchronization service and integrating binlog processing, which adds considerable complexity and cost.

Summary

Solution Selection

First, determine the latency tolerance of the product. If ultra‑low latency is required and data changes frequently, avoid caching altogether.

In most read‑heavy, write‑light scenarios, Solution 1 is sufficient and is the most widely adopted due to its zero development cost.

If more immediate consistency is needed, choose Solution 2, but without additional retry mechanisms.

For higher latency requirements, Solutions 3 and 4 provide push‑ and pull‑based mechanisms respectively; Solution 4 offers stronger reliability and ordering guarantees, making it the preferred choice when the extra effort is justified.

Conclusion

Generally, Solution 1 meets the needs of most applications. When strict latency is demanded, adopt Solution 4. In interview settings, start with the simplest solution and progressively discuss more complex alternatives as the interviewer probes deeper.