Knowing when to stop trusting a copy#
Reading cached data is easy. Knowing when that cached copy should stop being trusted is the harder part.
| Strategy | How it works | Main limitation |
|---|---|---|
| TTL only | Reuse until time expires | Stale until expiry |
| Delete on write | Remove copy after source commit | Deletion can fail or race |
| Update on write | Write source and cached value | Every representation must be correct |
| Versioned keys | Change product:42:v17 to a new version | Old keys need cleanup; readers need version |
| Event driven | Publish source changes to invalidators | Lag, duplicates, ordering, and missed events |
| Manual purge | Operator invalidates known scope | Slow and error-prone as a primary policy |
Invalidation can become a concurrency problem#
An old read returns after a new write
Request A: cache miss, reads old DB value
Request B: updates DB, deletes cache key
Request A: writes the old value into cache
Result: the cache is stale againPossible mitigations include version checks, ordered writes, bounded TTLs, write coordination, or compare-and-set behavior. Delayed double deletion can narrow particular races, but it is not a universal correctness guarantee.
Events help when several services or representations depend on one change. Consumers still need retries, deduplication, observability, and reconciliation. The future Messaging lessons cover those mechanics; they are not assumed here.
- Calling TTL “invalidation solved.”
- Deleting the cache before the database write without discussing a concurrent refill.
- Assuming invalidation events cannot be lost.
- Updating one cached representation while forgetting derived lists and aggregates.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- What if the DB update succeeds but invalidation fails?
- How do readers avoid repopulating an old value?
- How are missed events detected?
- Which operations require read-your-write behavior?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Caching challenges and strategiesAmazon Builders' Library
- RFC 9111: HTTP CachingIETF / RFC Editor
Reach this point to mark the lesson as read.