Cache invalidation
Cache invalidation
Bronze
Invalidating means removing cached copies when the data behind them changes. Deleting the entry is simpler and safer than updating it in place, but the delete must reach every copy — each server's own cache, the shared cache, every key built from the changed data — and beat any slow read still carrying the old value. Whatever it misses stays stale until its TTL runs out; invalidating everything at once trades stale reads for a flood of misses.
- Use when
- Data that changes and must not stay stale for a whole TTL · Several servers that each keep a local copy of shared data
- Avoid when
- Data that may be stale for its TTL — a TTL alone is simpler · Files that never change — publish them under a new name instead (core/cdn)
- Trade-offs
- Delete (one extra miss) vs update in place (fresh at once, but racing writers) · A narrow invalidation must know every key built from the data; a wide one empties the cache · Telling every server to drop a key costs bandwidth, and the message can be lost
- Requires
- Read-through & write-through
3 objectives · 9 misconceptions
- choose Choose 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.
- explain Explain 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.
- choose Choose 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).
- Not true: Updating the cached copy on every write is safer than deleting it.
- Not true: Deleting the cached entry before writing the database works just as well as after.
- Not true: Once the write and the delete are done, no reader can put the old value back.
- Not true: Deleting the key from the shared cache removes every cached copy of the data.
- Not true: A changed record only ever affects the one cache key named after it.
- Not true: With an invalidation on every write, cached entries don't need a TTL.
- Not true: When in doubt, flushing the whole cache is the safe way to invalidate.
- Not true: Invalidation messages always reach every server that holds a copy.
- Not true: Emptying the cache always pushes the database past what it can take, whatever the database's size.
Learn
Cache invalidationMembers~12 minPractice
No katas practice this yet.