Read-Through Cache
Read-through caching lets the cache load missing data from the backing store on a miss, keeping read logic out of application code. It suits read-heavy workloads and pairs with write-through for coherence.
A read-through cache sits in front of a slower data store and serves reads. When the requested item is present it is returned directly. When it is absent, the cache provider loads the value from the backing store, populates itself, and returns the result. The key difference from cache-aside is who loads the data: in read-through the cache library or service does it, not the application.
How It Works
The cache is configured with a loader function or data-access provider. On a get(key):
- The cache checks for the key.
- On a hit, it returns the cached value (optionally checking a time-to-live, or TTL).
- On a miss, the cache invokes the loader, stores the returned value with a TTL, and returns it.
Because loading is centralized, concurrent misses for the same key can be collapsed into a single backing-store call (request coalescing or "dog-pile" protection), which protects the database during traffic spikes. Many providers (Caffeine, Ehcache, Redis with a client-side loader, Hibernate second-level cache) implement this model.
When to Use It
Use read-through for read-dominated workloads where the same keys are requested repeatedly: product catalogs, user profiles, reference data, and rendered fragments. It is attractive when you want caching logic out of business code and prefer a uniform read path. It pairs naturally with write-through or write-behind so that writes keep the cache coherent.
Trade-offs
The first request for any key pays the full latency of a miss; cold caches after a restart cause a thundering herd unless coalescing is enabled. TTLs trade freshness against load: short TTLs reduce stale reads but increase backing-store traffic. Read-through couples the cache tightly to the data store through the loader, which can complicate testing and failover. It also caches only data accessed through the cache API; out-of-band writes to the store will not invalidate entries, so you need explicit invalidation or short TTLs to bound staleness.
Memory pressure is a constant concern. Eviction policies (LRU, LFU, TinyLFU) determine which keys survive; a poor policy on a skewed workload churns hot data. Size the cache to the working set, not the full dataset.
Related Patterns
Read-through is the read half of a coherent caching layer; combine it with write-through-cache or write-behind-cache for writes, and refresh-ahead-cache to hide miss latency on hot keys. Cache-aside is the application-managed alternative when you cannot configure a loader.
Example
A pricing service wraps its database behind a Caffeine read-through cache keyed by SKU with a 60-second TTL and request coalescing. During a flash sale, thousands of concurrent requests for the same hot SKU collapse into one database read; subsequent reads are served from memory in microseconds, and the 60-second TTL keeps prices acceptably fresh.