Skip to main content
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)