Read-through & write-through
Write-through updates the database and the cache in one write and answers only when both have it — so a read straight after a save hits the new value, but every save waits for the database, and the cache is still neither complete nor always right. It sits on top of lazy loading, not instead of it.
11 minMediumStation: Read-through & write-throughMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Cache basics: hit ratio, TTL, eviction
- Cache-aside
- Read-through & write-through
- Cache invalidation
- Cache stampede
What you'll be able to do
- 1Predict a write's latency and what a read straight after it returns under write-through versus write-around (cache-aside's invalidate on write).
- 2Choose write-through for data that is read soon after it changes and write-around for data written often or rarely re-read — keeping lazy loading underneath for everything else.
- 3Explain why write-through still leaves gaps — a new or replaced cache node starts without the data, changes made straight in the database never reach the cache, and a failure between the two writes leaves them disagreeing.
Inside the lesson
- steps
- 9
- questions
- 9
- simulations
- 2
You guess first, then run the system and see if you were right.
Step 1 · The setup
At the last stop, Pixel used cache-aside: when a caption changes, the app writes the database, then deletes the cached copy.
Back on the feed API: with room for every feed, its cache answers about 95% of 200 reads a second, and 40 caption edits arrive a second too. People edit a caption and reload at once to check it. With the copy deleted, that reload misses and waits for the database before it gets the new caption — and until the delete lands, another reader may still get the old one.
The team wants the reload to find the new caption in the cache already, so each edit will write it to the database and the cache.
Steps 2–9 are for members