Cache Consistency Strategies for MySQL Using Redis

Background

Caching is a useful concept in software development, and database caching is a scenario that inevitably appears in projects. Ensuring cache consistency is a frequent interview question, so this article summarizes suitable consistency solutions for different requirements.

What Is Cache

Storage speed varies; caching stores the results of slower storage in faster storage.

The upper layers of the storage pyramid can serve as a cache for the lower layers.

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

Why Cache Is Needed

MySQL provides full ACID guarantees, but reliability and persistence cause its performance to be relatively low, especially under high‑concurrency queries, leading to system instability and latency.

According to the principle of locality, 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 cache to become inconsistent. The tolerable inconsistency window depends on business specifics, but most applications require eventual consistency.

Redis as MySQL Cache

Typical development uses 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 MySQL should be accessed directly. Most scenarios aim for eventual consistency.

Solution Options

Option 1

Rely on key expiration; when MySQL updates, Redis is not updated.

This approach is simple but may keep stale data for a long time, especially with frequent reads and long expiration periods.

Advantages:

Low development cost and easy to implement.

Low management cost with a low probability of issues.

Disadvantages:

Depends entirely on expiration time; short times cause frequent cache misses, long times cause long‑lasting inconsistency.

Option 2

Build on Option 1 by also updating Redis synchronously when MySQL is updated.

Advantages:

Update latency is smaller than Option 1.

Disadvantages:

If MySQL update succeeds but Redis update fails, the system degrades to Option 1.

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

Option 3

Optimize Option 2 by introducing a message queue (e.g., Kafka) to handle Redis updates asynchronously, with a consumer service applying the updates.

Advantages:

The message queue provides a single handle and many clients support local buffering, alleviating the connection‑count problem of Option 2.

Achieves logical decoupling between services.

Message queues are reliable; with manual commits, at‑least‑once delivery to Redis is possible.

Disadvantages:

Does not solve ordering issues; concurrent updates may be applied out of order, leading to inconsistency.

Introducing a message queue and a consumer service adds cost and the risk of duplicate consumption.

Option 4

Subscribe to MySQL binlog to update Redis. A dedicated sync service acts as a MySQL slave, parses binlog events, and updates Redis accordingly.

Advantages:

When MySQL load is moderate, latency is low.

Fully decoupled from business logic.

Solves ordering problems.

Disadvantages:

Requires building a separate sync service and integrating binlog replication, which incurs significant cost.

Summary

Solution Selection

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

Generally, Option 1 is sufficient. The author consulted 4‑5 teams, and most use Option 1 because caching is typically applied to read‑heavy, write‑light scenarios where some latency is acceptable. Option 1 has no development cost and is practical.

If you need more immediate update visibility, choose Option 2, though retry mechanisms are unnecessary.

Options 3 and 4 target scenarios with higher latency demands; Option 3 uses a push model, Option 4 a pull model. Since Option 4 offers stronger reliability, if you are willing to invest in the additional infrastructure, it is the preferred choice.

Conclusion

In most cases, Option 1 is enough. For high‑latency‑sensitive situations, directly adopt Option 4. In interview settings, you can start with the simple solution and progressively discuss more complex alternatives as the interviewer probes further.