Cache invalidation
When data changes, delete the cached copy rather than update it, in the right order and guarded against a slow read — and reach every copy, from each server's own cache to every key built from the data, with a TTL as the backstop. Flushing everything isn't safe; it trades stale reads for a flood of misses.
12 minMediumStation: Cache invalidationMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Cache-aside
- Read-through & write-through
- Cache invalidation
- Cache stampede
- Stop the loop
What you'll be able to do
- 1Choose between deleting and updating the cached copy when data changes, and order the steps so that a slow or racing read can't put the old value back.
- 2Explain why one change has to invalidate every copy — each server's local cache, the shared cache, keys built from the data — and how a shared cache or invalidation messages get there, with a TTL catching any copy that is missed.
- 3Choose how wide to invalidate — one key, every key built from the change, or the whole cache — weighing missed keys (stale reads until the TTL) against invalidating too much (a burst of misses on the database).
Inside the lesson
- steps
- 10
- questions
- 8
- simulation
- 1
You guess first, then run the system and see if you were right.
Step 1 · The setup
The last stop ended on a warning: updating a cached copy in place has its own race. Pixel is about to meet more than one problem.
A user renames an album. Pixel's code writes the database and deletes the album's entry in the shared cache — yet some views keep showing the old name. Where do those old names come from?
A teammate proposes a simple rule: whenever anything changes, empty the whole cache, “to be safe”. Pixel's feed takes 200 reads a second, and a warm cache answers about 95% of them.
Steps 2–10 are for members