Topic 10.4
Write-through
In one line
Writes go to the cache first and the cache synchronously writes the store — strong-ish, and always-on freshness.
Think of it like this
Updating your phone's contacts app AND your paper address book at the exact same time, every single time, so they're always in sync — safer, but every update now takes two steps instead of one.
Key ideas
- 01
Every write: update cache AND store (cache initiates or participates).
- 02
Reads are always fresh-ish (the cache was just written) — removes the eviction-race half of cache-aside.
- 03
Cost: write latency gets the double write — the write path is now slower, and the cache MUST be durable-adjacent.
- 04
When it shines: a cache that doubles as the source of fast reads with low read:write skew.
- 05
Failure question: if the cache dies before flushing to the store, data is lost unless write-ahead ordered.
- 06
Interview note: 'write-through buys read freshness but taxes the write path — I'd use it for low-write, hot-read data'.
Java / Spring map
- →
Spring Cache Put + DB transaction in the same method — beware: two ugly outcomes if they aren't atomic.
Code & diagrams
Explain without notes
What is the atomicity problem between 'update cache' and 'update DB' — and what's the ordering rule that minimizes damage?
Practice
Specify write-through for a 'current stock count' that reads 1000x/s but writes once a minute.
Trade-offs
- ↔
Write-through sacrifices write latency for read freshness; write-back reverses it (next topic).
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 contrast write-through vs write-back in one sentence each.