阅读中文版本

Read-Through Caching

A read-through cache loads a missing entry from the origin on demand, so application code always reads from the cache and never sees a load step.

Definition

Read-through caching is a pattern in which the cache itself fetches from the backing store on a miss and stores the result, so callers issue a single read against the cache.

It simplifies application code in gateways and data access layers that want caching to be transparent. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

The cache owns the load path, so a miss triggers a fetch, a store, and a return, and every caller sees the same interface whether the data was cached or not.

Freshness still depends on a time to live or explicit invalidation, so read-through does not solve staleness by itself.

Trade-offs and alternatives

Concurrent misses for the same key can still stampede the origin, so read-through is often combined with request deduplication or a short lock around the load. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that read-through automatically keeps entries fresh forever. Another is that it removes the need to choose a time to live. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to using read-through for data that must never be stale and to letting a single missing key trigger an expensive uncached fetch storm. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Negative Versus Positive Caching, Cache Preloading and Warming, Distributed Caching.