~learn.
0:00 / 1:18
W04 · Caching

You deleted the cache key. The old price came back anyway.

transcript

You update a price. You delete the cache key. Textbook. The page still shows the old price. Until the TTL runs out.

Here's the order. The transaction updates the row. Not committed yet. Then it deletes the cache key. Still inside the transaction. Another request misses. It reads the database, and sees the old value. Then the commit lands. Database new, cache old. Nothing deletes it again.

Before the commit, every other reader still sees the old row. So any miss in that gap refills the cache with it. The fix is ordering. Commit first. Then invalidate. Now the next miss can only load the new value.

But one race remains. A reader loaded the old row just before the update. Facebook's fix is leases. On a miss, the reader gets a token. A writer's invalidation voids that lease. So the reader's stale fill is rejected. And readers never block writers.

Delete before the commit, and readers put the old value right back. Commit first. Then invalidate. And keep a TTL as the safety net.

Full breakdown in the lecture.