Database Cache Consistency Strategies: Using Redis as a MySQL Cache

Background

Caching is a very useful concept in software development, and database caching is an inevitable scenario in projects. Ensuring cache consistency is a frequent interview question, so this article summarizes various consistency solutions and helps choose the most suitable one based on different requirements.

What Is Cache

Storage speeds differ; caching temporarily stores the results of slower storage in faster storage.

As shown in the diagram, the upper layer of the storage pyramid can serve as a cache for the lower layer.

This discussion focuses on database cache scenarios, using Redis as a cache for MySQL as a case study.

Why Cache Is Needed

MySQL, while supporting full ACID properties, often has lower performance under high concurrency due to reliability and persistence overhead, leading to instability and latency. According to the locality principle, 80% of requests hit 20% of hot data; in read‑heavy, write‑light scenarios, adding a cache layer greatly improves throughput and robustness.

Existing Problems

Data in the database may change over time, causing the cached data to become inconsistent. The tolerable inconsistency window depends on business requirements, but most applications aim for eventual consistency.

Redis as MySQL Cache

Typical development patterns use MySQL for storage and Redis as a cache to accelerate and protect MySQL. When MySQL data updates, how should Redis stay synchronized?

Strong consistency synchronization is too costly; if strong consistency is required, caching is unnecessary and direct MySQL access suffices. Usually, eventual consistency is considered.

Solutions

Solution 1

Set an expiration time for the key; when MySQL updates, Redis is not updated. This is simple but may keep stale data for a long time, especially with frequent reads and long TTLs.

Advantages:

Low development cost, easy to implement.

Low management cost, lower probability of issues.

Drawbacks:

Fully dependent on TTL; short TTL causes frequent cache misses, long TTL leads to prolonged inconsistency.

Solution 2

Based on Solution 1, add a fallback TTL and update Redis simultaneously when MySQL updates.

Advantages:

Update latency is smaller compared to Solution 1.

Drawbacks:

If MySQL updates succeed but Redis update fails, the system degrades to Solution 1.

In high‑concurrency scenarios, the business server must connect to both MySQL and Redis, doubling connection resources and potentially causing connection‑count issues.

Solution 3

Optimize the synchronous Redis update of Solution 2 by introducing a message queue (e.g., Kafka) to handle Redis updates asynchronously.

Advantages:

Message queue provides a single handle; many clients support local buffering, alleviating the connection‑count problem of Solution 2.

Achieves logical decoupling between services.

Message queues are reliable; with manual commits, at‑least‑once delivery to Redis can be ensured.

Drawbacks:

Does not solve ordering issues; if two requests modify the same row, the execution order in MySQL may differ from the order they enter Kafka, leading to inconsistency.

Introducing a message queue and a consumer service adds considerable cost.

Solution 4

Subscribe to MySQL binlog to update Redis. Build a consumer service that acts as a MySQL slave, parses binlog events, and updates Redis accordingly.

Advantages:

Low latency when MySQL load is moderate.

Fully decoupled from business logic.

Solves ordering problems.

Drawbacks:

Requires building a separate synchronization service and integrating binlog mechanisms, which incurs high cost.

Summary

Solution Selection

First confirm product latency requirements; if latency must be extremely low and data may change, avoid caching.

Generally, Solution 1 is sufficient; most teams use it for read‑heavy, write‑light scenarios because it has no development cost.

If you need more immediate updates, choose Solution 2, but without extra retry guarantees.

Solutions 3 and 4 target high‑latency‑sensitive workloads; Solution 4 offers stronger reliability and is recommended if you are willing to invest in message‑processing infrastructure.

Conclusion

In most cases, Solution 1 is enough. For high‑latency requirements, directly adopt Solution 4. In interview scenarios, start with the simple solution and progressively discuss more complex ones as the interviewer probes deeper.