CDN Invalidation Storm

When telling the cache to forget everything takes down your backend.

The idea

A CDN (Content Delivery Network) sits in front of your servers, caching images and pages so your servers don't have to work hard. But what happens if you push a bad CSS file and need to clear the cache? If you tell the CDN "Invalidate EVERYTHING" (a wildcard invalidation), the CDN instantly drops all cached files. The next second, 10,000 users ask the CDN for those files, and the CDN forwards all 10,000 requests straight to your fragile origin servers, crushing them instantly.

How it works (Cache Busting vs Invalidation)

Instead of manually invalidating the CDN (which takes time to propagate globally and causes storms), you should use Cache Busting. You change the URL of the asset whenever the content changes.

# The bad way (Manual Invalidation)
# HTML: 
# You update style.css on the server.
cdn_api.invalidate_cache("/style.css") # ⚠ Causes a localized traffic spike!

# The good way (Cache Busting / Fingerprinting)
# HTML: 
# When you change the CSS, the build tool changes the hash in the filename.
# HTML: 

# The CDN has never seen 'style.b8x1c9.css', so it fetches it exactly ONCE.
# The old 'style.a3f9b2.css' just sits in the cache until it expires naturally.
# No manual invalidation needed! No storms!

Cost

Invalidating a CDN cache is technically free, but the cost to availability is massive. Cache busting requires setting up a build pipeline (like Webpack or Vite) to inject hashes into filenames, but makes deployments entirely safe.

Watch out for

• Index.html: You cannot cache-bust your root index.html (because the user types yoursite.com, not yoursite.com/index.a1b2.html). Your root HTML must have a very short cache TTL (e.g. 60 seconds), while all JS/CSS/Images it references use infinite TTLs and cache-busting filenames.
• Wildcard Invalidations: Never run invalidate /* in production unless you are under an active, critical attack. It takes down more sites than it saves.