Caching
Cache Invalidation
"There are only two hard problems in computer science: cache invalidation and naming things." Getting a cache to stop serving stale data — without either thrashing the source of truth or serving it forever — is genuinely hard.
- TTL-based expiry: simple and bounded, but the bound is arbitrary — too short thrashes the database, too long serves stale data for longer than acceptable
- Explicit invalidation on write: correct in principle, but every code path that writes the source of truth must remember to invalidate the cache — one missed path reintroduces staleness silently
- Write-through sidesteps invalidation by keeping the cache updated at write time instead of correcting it after the fact
- Versioned or tagged keys (embedding a content hash or version number in the cache key) avoid invalidation entirely — an old version simply ages out on its own, never invalidated because it is never looked up again
- Invalidating a distributed cache cluster requires a broadcast mechanism (pub/sub to every node) — and there is always a real, non-zero propagation window before every node has processed it
| Strategy | Correctness | Operational cost |
|---|---|---|
| TTL only | Bounded staleness, not zero | Very low — no coordination needed |
| Explicit invalidation | Correct if every write path remembers | Moderate — broadcast + race handling |
| Versioned keys | Correct by construction | Higher memory (old versions linger until TTL) |