Avoid Stale Data: Master Cache Aside, Read‑Through, Write‑Through & Write‑Behind Strategies

Cache Aside

The Cache aside (also called 旁路缓存) pattern is widely used. For a read request, the application first checks the cache; if it hits, the data is returned, otherwise the request penetrates to the database, the result is written back to the cache, and finally returned to the client.

For a write request, the database is updated first and then the corresponding cache entry is deleted.

Cache Aside Pitfalls

Pitfall 1: Update database then update cache

When two concurrent write requests each update the database and then the cache, the cache can end up with stale data. Example sequence:

Write request 1 updates DB, setting age to 18.

Write request 2 updates DB, setting age to 20.

Write request 2 updates cache, setting age to 20.

Write request 1 updates cache, setting age to 18.

The database holds age=20 but the cache holds age=18, producing dirty data.

Pitfall 2: Delete cache before updating database

In a read‑write concurrent scenario, deleting the cache first and then updating the database can also lead to inconsistency. The sequence shows a read miss, a DB read, cache write‑back, and finally a DB update, leaving the cache with an outdated value.

Pitfall 3: Update database then delete cache

Even this seemingly safe order can cause temporary inconsistency if a read request occurs between the DB update and the cache deletion. The article notes that the probability is low because DB writes are usually slower than cache operations, but a fallback is to set an expiration time on cache entries.

Read‑Through

With the Read‑Through strategy, the application does not manage cache and database directly. Instead it delegates all data access to a Cache Provider that abstracts the underlying storage. The provider reads from the cache if possible, otherwise fetches from the database and writes the result back to the cache.

Application interacts only with the Cache Provider.

Read‑Through reduces load on the data source and adds resilience; if the cache service fails, the provider can fall back to the database.

Write‑Through

In the Write‑Through model, every write operation goes through the Cache Provider, which updates both the underlying database and the cache atomically. This keeps cache and data source strongly consistent.

Write‑Behind (Write‑Back)

The Write behind (or Write back) approach updates only the cache immediately; the Cache Provider flushes changes to the database asynchronously in batches. This yields very fast write performance, suitable for high‑write workloads, but sacrifices strong consistency and should be used cautiously.

Summary

Cache update strategies can be grouped into three families:

Cache Aside – typically update the database first, then delete or invalidate the cache, often adding a TTL as a safety net.

Read/Write‑Through – a Cache Provider handles reads and writes, abstracting the underlying storage from the application.

Write‑Behind – writes affect only the cache initially; the provider syncs to the database later, offering speed at the cost of eventual consistency.

Choosing the right strategy depends on consistency requirements, read/write patterns, and system latency characteristics.