How to Ensure Data Consistency When Writing to Cache and Database Simultaneously

How to Ensure Data Consistency When Writing to Cache and Database Simultaneously

When optimizing a system, data can be divided into three levels based on real‑time requirements. Level 1 includes order and payment transaction data that demand high timeliness and accuracy, so they bypass any cache and interact directly with the database. Level 2 consists of user‑related data that are read‑heavy and write‑light, making Redis a suitable cache. Level 3 covers payment configuration data that are small in volume, read‑frequent, and rarely modified, so they are cached in local memory.

Any use of cache—whether local memory or Redis—introduces synchronization problems because the cache cannot automatically detect modifications made directly to the database, leading to inconsistency between the two stores.

Solutions

We list four common strategies and discuss their advantages and disadvantages.

Update the database first, then update the cache.

Update the database first, then delete the cache.

Update the cache first, then update the database.

Delete the cache first, then update the database.

Update the Database First, Then Update the Cache

This approach is rarely used because many cached values are derived from complex calculations rather than a direct database query. Updating the cache after every write can be costly, especially when write traffic is high and read traffic is low, leading to performance degradation.

For example, if a value of 1 in the database receives ten incremental write requests without any reads, updating the cache ten times creates a lot of stale data. Deleting the cache instead and letting the next read repopulate it is more efficient.

Update the Cache First, Then Update the Database

This scenario is essentially the same as the first one and is generally not recommended.

Delete the Cache First, Then Update the Database

This method can cause inconsistency when two requests arrive concurrently: request A deletes the Redis entry and updates the database, while request B reads the missing cache, fetches the stale value from the database, and repopulates Redis before request A’s transaction commits.

The simplest mitigation is the delayed double‑delete strategy.

When using MySQL read‑write splitting, replication lag between master and slave can also cause stale reads. In a scenario where request A updates and deletes Redis, then the master updates and replicates to the slave, request B may read the stale value from the slave before replication completes.

The remedy is to force cache‑filling queries to read from the master database.

Update the Database First, Then Delete the Cache

If the cache‑deletion step fails after a successful database update, subsequent reads will continue to return stale data.

A common compensation technique is to use a message queue: after the database update, if cache deletion fails, the Redis key is sent as a message; a consumer later retries the deletion.

Request A updates the database.

Cache deletion fails and the key is sent to a message queue.

The consumer receives the message and retries the deletion.

However, this approach tightly couples business code with infrastructure. An alternative is to subscribe to MySQL binlog events and update the cache based on those logs, which decouples the systems but adds operational complexity.

Conclusion

Each strategy has trade‑offs. Deleting the cache before updating the database can be solved by forcing read‑through queries to hit the master, which adds code intrusion but avoids extra services. Using binlog subscription provides a clean separation at the cost of increased system complexity. Ultimately, the choice depends on the specific business requirements; there is no universally best solution.