Cache Invalidation

Caching makes reads fast by keeping copies; invalidation is the price — deciding when a copy no longer speaks for the source. It is hard because the moment of staleness is invisible: nothing tells the cache that the underlying row changed. Every strategy is a different answer to "how stale is acceptable, and who is responsible for noticing?" — and "nobody thought about it" is itself an answer, usually discovered in production.

TTL suits data where bounded staleness is fine (a product page a minute old). Explicit purge — delete the key when the source changes — suits data that must be right (a cart, a permission). Versioned keys sidestep purging entirely: bake a version or hash into the key or URL (app.3f9c2.js), publish new content under a new key, and let the old expire — which is exactly how CDN asset caching works, and why immutable assets can be cached for a year.

Purge-on-write couples writers to every cache that holds the data — miss one path (a bulk job, another service) and staleness returns. Synchronised expiry causes thundering herds: a thousand requests miss at once and stampede the database. Delete-then-repopulate has a race where a stale read refills the cache after the purge. The recurring lesson: freshness guarantees get expensive fast, so demand only what the data actually needs.

Give every entry a TTL even when you also purge — bugs happen, and the TTL is the backstop. Prefer delete over update on write (let the next read repopulate), add jitter to expiries, and use stale-while-revalidate to serve the old value while fetching the new. Version keys for anything immutable. And write the freshness contract down per data type — "how stale is acceptable" is a product decision wearing an engineering costume.