Your CDN saved you from explaining a 400ms load time to your VP.
Then your deploy shipped. And nobody got the fix.
Here's what happened:
Your edge nodes were still serving the old JS bundle — TTL hadn't expired. You triggered a cache purge manually. But you hit the wrong environment. Prod kept serving the stale version for 6 more hours.
You need a CDN configuration that handles invalidation reliably under deploy pressure. Which one do you pick?
A) Anycast routing + stale-while-revalidate + event-driven purge via API on deploy
B) Unicast routing + aggressive TTLs + manual cache purge via dashboard
C) Anycast routing + long TTLs + tag-based invalidation via API
D) Anycast routing + short TTLs + no invalidation strategy (let caches expire naturally)
Pick A, B, C, or D — and tell me what your actual CDN invalidation story is. Full breakdown in the comments.
Top comments (4)
✅ A — Anycast + stale-while-revalidate + event-driven purge — the right answer
Anycast advertises the same IP from multiple PoPs. BGP routes each user to the closest edge automatically. Tokyo user hits Tokyo — not Virginia.
Stale-while-revalidate: serve the cached version immediately, fetch a fresh copy in the background. Users never wait on a cache miss to resolve.
Event-driven purge: your CI/CD pipeline fires a Cloudflare or CloudFront API call on every deploy, targeting exactly the changed assets. No manual steps. No wrong-env clicks. No 2 AM mistakes.
C — Anycast + long TTLs + tag-based invalidation — solid, but has a trap
Tag-based invalidation (Cloudflare Cache-Tag, Fastly surrogate keys) lets you group objects and purge entire logical groups in one API call. New product images? Invalidate tag:product-images. Clean and surgical.
The trap: long TTLs work perfectly when your deploy pipeline is robust. But if your invalidation API call fails silently during an incident — when you're moving the fastest — you're serving the wrong version for hours with no TTL fallback to save you.
Option A's stale-while-revalidate degrades more gracefully when your pipeline gets messy.
❌ D — Short TTLs, no invalidation
"Short TTLs = always fresh" is the most expensive misconception in CDN config.
Every TTL expiry is a potential cache stampede. 200k RPS at peak, TTL expires on a hot endpoint, every PoP fires a simultaneous request to your origin. You go from 0 to 200k RPS in 2 seconds.
And you have zero control for hotfixes. You just wait for the TTLs to drain.
❌ B — Unicast + aggressive TTLs + manual purge
Unicast means one edge region. Your Tokyo users are routing to Virginia. You've deployed a CDN and you're routing past it.
Manual dashboard purges during a deploy: someone will forget, click the wrong environment, or skip it entirely at 2 AM. Aggressive TTLs shrink the damage window — they don't make invalidation reliable.