Avoid Stale Data: Pitfalls and Best Practices for Cache Aside, Read‑Through, Write‑Through, and Write‑Behind

Background

In large‑scale systems a cache is often placed in front of the database to reduce load. Because the cache holds a copy of the data, the cache and the database can become inconsistent, leading to stale reads. Keeping the two data stores synchronized is therefore essential.

Cache‑Aside (旁路缓存)

Read flow : the application first queries the cache. If the key is present (cache hit) the value is returned immediately. If the key is missing (cache miss) the application reads the value from the database, writes the result into the cache, and returns it to the client.

Write flow : the application updates the database first, then deletes the corresponding cache entry so that the next read will repopulate the cache with fresh data.

Pitfalls of Cache‑Aside

Pitfall 1 – Update database then update cache

When two concurrent writes each update the database and then the cache, the later database write can be overwritten by the earlier cache write, leaving the cache stale.

Write 1 updates DB: age = 18 Write 2 updates DB: age = 20 Write 2 updates cache: age = 20 Write 1 updates cache: age = 18 Result: DB holds age = 20 but cache holds age = 18.

Pitfall 2 – Delete cache before updating database

If a write deletes the cache first, a concurrent read may miss the cache, fetch the old value from the database, and write that stale value back to the cache before the database is updated.

Write deletes cache.

Read misses cache, reads DB (old age = 18), writes it to cache.

Write updates DB to age = 20.

Result: DB age = 20, cache age = 18.

Pitfall 3 – Update database then delete cache

Even with the recommended order (DB update → cache delete), a read that occurs between the two steps can repopulate the cache with stale data.

Read misses cache, reads DB ( age = 18).

Write updates DB to age = 20 and deletes cache.

Read writes the previously fetched value ( age = 18) back to cache.

Result: DB age = 20, cache age = 18. This race is rare because DB writes are usually slower than cache writes, but it can happen.

Mitigation

Setting a short TTL (time‑to‑live) on cached entries limits the window of inconsistency; after expiration the cache will be refreshed from the database.

Read‑Through

With the read‑through pattern the application never talks to the database directly. It calls a cache provider (or cache client) that abstracts the data source. On a cache miss the provider automatically fetches the value from the database, stores it in the cache, and returns it to the caller.

Read‑through reduces load on the database during heavy read traffic and provides resilience: if the cache service fails, the provider can fall back to the database.

Write‑Through

In write‑through every write operation is routed through the cache provider, which synchronously updates both the cache and the underlying database. This guarantees strong consistency because the cache and the database are always written together.

Write‑Behind (Write‑Back)

Write‑behind (also called write‑back) updates the cache immediately and defers persisting the changes to the database. The cache provider batches the pending writes and flushes them to the database after a configurable interval.

Advantages : Very fast write latency; suitable for write‑heavy workloads.

Disadvantages : Cache and database are not strongly consistent; not appropriate for systems that require strict consistency.

Summary of Cache Update Strategies

Cache‑Aside : Application updates the database first, then deletes (or expires) the cache entry. Adding a TTL provides a safety net for rare race conditions.

Read‑Through / Write‑Through : A cache provider abstracts all reads and writes. The provider ensures the cache and database stay in sync automatically.

Write‑Behind : Writes are applied to the cache instantly and flushed to the database asynchronously, offering high write throughput at the cost of eventual consistency.