Cache Consistency Between MySQL and Redis: Design Patterns and Best Practices

MySQL is a persistent database that guarantees data reliability, while Redis serves as an in‑memory cache to improve data access performance. Keeping the data in both systems consistent is a classic challenge because updates must affect two separate systems, often leading to temporary inconsistencies.

1. How Cache Inconsistency Occurs

Inconsistency typically appears when data changes: the database and cache are updated separately, creating a time gap during which they diverge, especially under concurrent read/write operations.

2. Cache‑Update Design Patterns

Four main patterns are commonly used:

Delete‑then‑Update Database – The cache is cleared before the database is updated. This can leave stale data in the cache for a period and is generally discouraged.

Update Database then Invalidate Cache (Cache‑Aside) – The database is updated first, then the related cache entry is removed, forcing subsequent reads to fetch fresh data from the database.

Read/Write‑Through – All writes go to the cache, which synchronously writes to the database; reads are served from the cache, and on a miss the cache loads from the database.

Write‑Behind (Asynchronous) – Writes update the cache only; the cache later propagates changes to the database asynchronously, offering high performance but risking data loss if the cache fails before persisting.

2.1 Delete‑then‑Update Database

In a concurrent scenario, the sequence may be: client 1 deletes the cache entry, client 2 reads the cache (miss), fetches from the database and repopulates the cache, then client 1 updates the database, leaving the cache with stale data.

2.2 Update Database then Invalidate Cache (Cache‑Aside)

The workflow: client 1 updates the database, client 2 reads the cache (hits old data), client 1 invalidates the cache, client 3 later reads the cache (miss) and repopulates it from the database. The cache eventually becomes consistent, with only a brief inconsistency window.

2.3 Read/Write‑Through Pattern

Clients write directly to the cache; the cache synchronously updates the database. Reads are served from the cache, and on a miss the cache fetches from the database and stores the result. This approach yields near‑zero inconsistency but requires cache modification.

2.4 Write‑Behind (Asynchronous) Pattern

Clients update the cache only; the cache later writes the changes to the database asynchronously. This provides excellent read/write performance but sacrifices strong consistency and can lose data if the cache crashes before persisting.

Conclusion

Each cache‑update pattern has trade‑offs; none is perfect. System designers should choose the approach that best fits their specific business scenario rather than striving for an unattainable perfect design.