Cache invalidation / purge
Telling the caches to throw away their copy of something you changed, so the next visitor gets the new version instead of the old one.
See it
What it is
Every cached copy is a small lie that was true when it was made. Invalidation is how you retract it: you tell the CDN (and sometimes the browser) to drop what it has, so the next request goes back to origin for the fresh version. Flavors, from surgical to nuclear: purge a single URL, purge a path prefix or wildcard, purge by surrogate key / cache tag (one call clears every page tagged 'product-42'), or purge everything.
Reach for it after a content edit that must go live now: a corrected price, a pulled blog post, a swapped hero image. For code and assets, do not purge at all. Give the file a content hash in its name (app.9f2c1b.js) so a new build is simply a new URL, and the old copy can rot in caches forever.
Two traps. 'Purge everything' after a deploy sends every edge to your origin at once, which is a cache stampede and can be worse than the stale content was. And you cannot purge a browser: a file you sent with max-age=31536000 stays on that laptop until it expires, no matter what you do at the edge.
Ask AI for it
Add a post-deploy cache invalidation step. Call the CDN provider's purge API for only the paths whose content changed, or by surrogate key / cache tag where the provider supports it, never a full purge-everything. Tag responses at the origin with a Surrogate-Key header per entity id so one call clears every page showing that entity. Keep hashed static assets out of the purge entirely, log the purged keys, and retry with exponential backoff on failure.