Pattern
Read-through cache
Problem
Your application logic has to duplicate cache-management code everywhere it reads — check cache, on miss read DB, populate cache, return.
Context
You want the cache to look like a transparent layer: the application asks the cache for data, the cache handles the DB fallback internally.
Solution
The cache library or service intercepts reads. On hit, returns. On miss, calls the loader function (which reads from DB), stores the result with TTL, and returns. The application code just calls cache.get(key) — no explicit fallback.
Trade-offs
- Every miss pays a synchronous DB round-trip through the cache layer
- Cache library needs to know how to load data — coupling
- Harder to selectively cache different types of data with different rules
Failure modes
- Cold cache creates a stampede on start (same as cache-aside)
- Loader errors bubble up as cache errors — need clean error propagation
- TTL choice still hard
When to use
- You want cache logic centralized, not sprinkled through app code
- You're using a cache library (Caffeine, Ehcache) that supports this natively
When NOT to use
- You want fine-grained control over what's cached and when
- Cache and DB have different semantics (e.g., cache is per-user, DB is not)