Topic 10.3
Read-through
In one line
The cache loads from the DB by itself on a miss — the app only ever talks to the cache.
Think of it like this
A vending machine that automatically restocks itself from the warehouse the moment it runs out of a snack, without you ever seeing the restocking happen — you just always get your snack.
Key ideas
- 01
Cache (e.g. Redis with an external loader, or a library like Caffeine) owns the miss-fetch.
- 02
App code: just get(key) — simpler callers, consistent loading logic in one place.
- 03
Same stampede risk as cache-aside; the loader must be single-flight.
- 04
Deployment nuance: read-through caches sit beside the store and must be warmed (data may not pre-exist).
- 05
Interview: 'read-through with a single-flight loader' is the polished answer to any 'where does the cache come from' question.
Java / Spring map
- →
Caffeine/Spring Cache read-through, or Redis with an app-level loader — the loader is just a Function.
Explain without notes
Read-through vs cache-aside — who technically handles the DB call, and why might the team care?
Practice
Convert the ProfileService to read-through and compare the caller's view of the world.
Trade-offs
- ↔
Cleaner caller, but the loader lives where the app code is — same failure modes as cache-aside.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can describe read-through and name its stampede requirement.