Read-through vs write-through cache
Two caching strategies that optimize opposite paths — one makes reads self-loading, the other keeps the cache and database in lockstep on writes.
Same goal, different path
Both keep a cache in front of a database; they differ in which operation owns the synchronization — reads or writes. You often use them together.
Read-through (optimizes the read path)
The application always reads from the cache, and the cache itself loads from the database on a miss:
read → cache → (miss) → cache fetches from DB → store → return- Wins: app code is simple (it only talks to the cache); only requested data is cached; loading logic lives in one place.
- Costs: the first read of any key is a slow miss; data can go stale until it expires (pair with a TTL); a cold cache hammers the DB.
- Best for: read-heavy workloads where the same items are read repeatedly.
(Read-through is the cleaner cousin of cache-aside, where the app — not the cache — does the DB fetch. Same read-optimizing idea.)
Write-through (optimizes consistency on write)
Every write goes to the cache and the database together, synchronously, before the write is acknowledged:
write → cache + DB (both, synchronously) → ack- Wins: the cache is never stale — a read right after a write sees the new value; no separate invalidation needed.
- Costs: every write pays two writes’ latency; you may cache data that’s never read again (wasteful unless paired with write-around).
- Best for: data that’s written then read soon and must be fresh.
Why they pair up
Read-through keeps reads fast and self-loading; write-through keeps the cached copy fresh. Combine them and you get a cache that lazily fills on reads and stays consistent on writes — at the cost of slower writes. If writes are bursty and you can tolerate a crash-loss window, swap write-through for write-back (async flush) to make writes fast too.
The decision
| If… | Choose |
|---|---|
| Reads dominate, some staleness OK | Read-through (+ TTL) |
| Writes must be immediately visible | Write-through |
| Writes are bursty, speed > durability | Write-back |
| Written data rarely re-read | Write-around (skip cache on write) |
The interview cue
“Reads are 100:1, so I’ll read-through the cache with a short TTL; for the few fields that must be fresh the instant they change, I’ll write-through so the cache never lies.” Naming which path each strategy optimizes — and that they compose — is the signal. (See the caching lesson in Chapter 2 for the full strategy set.)