CDN Invalidation

Distributed SystemsSenior

The Question

How does CDN cache invalidation work?

What a Strong Answer Covers

• All three methods. Versioned URLs = cache-busting.

Senior-Level Answer

A CDN caches origin responses at geographically distributed edge nodes so that subsequent requests are served locally without hitting the origin. Cache invalidation is the mechanism by which stale copies at those edge nodes are replaced or discarded.

**TTL-based expiration** is the default mechanism. The origin sets `Cache-Control: max-age=<seconds>` (or the legacy `Expires` header). Each edge node honours this value independently; once a cached object's age exceeds max-age, the next request triggers a conditional revalidation (`If-None-Match` / `If-Modified-Since`) or a full re-fetch. Because edge nodes are globally distributed and may have cached the object at different times, expiration is not simultaneous—different users may see stale content for different durations within the TTL window.

**API-based purge** (also called instant purge or cache bust) lets operators send an explicit invalidation request—typically a DELETE or POST to the CDN's management API—that propagates a purge signal to all edge nodes. Most major CDNs (Cloudflare, Fastly, Akamai) guarantee propagation within seconds. Purge can target individual URLs, URL patterns (surrogate keys / cache tags), or entire zones. Cache tags are particularly powerful: a single tag like `product:42` can be attached to all pages that embed product 42, and one tag purge clears all of them atomically.

**URL versioning (cache-busting)** sidesteps invalidation entirely by embedding a content hash or build ID in the asset URL (e.g., `app.a3f9c1.js`). The old URL is simply abandoned; it expires naturally. This is the preferred approach for static assets in CI/CD pipelines because it eliminates the race condition between deploy and purge propagation.

**Stale-while-revalidate** is a middle-ground directive: the CDN serves the stale object immediately while fetching a fresh copy in the background. This trades brief staleness for zero-latency updates and is ideal for content that is frequently updated but where millisecond accuracy is not required (news feeds, dashboards).

The hard problem is the window between a deploy and full purge propagation—requests hitting un-purged edges can return stale HTML referencing already-deleted asset URLs. The canonical mitigation is to deploy assets before HTML (atomic immutable asset deploy, then HTML purge), ensuring that any HTML version—old or new—references valid assets.

What Separates a 2/3 from a 3/3

Common Mistakes

• Assuming purge is instantaneous and globally consistent—propagation takes seconds to tens of seconds.
• Conflating CDN TTL with browser TTL; Cache-Control is honoured by both and they can diverge.
• Forgetting that URL versioning is only viable for immutable assets, not HTML or API responses.
• Not mentioning cache tags when asked about bulk invalidation patterns.

Follow-Up Questions

• How do you handle a CDN purge race condition during a rolling deploy? — Lead with: deploy immutable assets first, then swap HTML; ensure old HTML can still load old asset URLs.
• What are surrogate keys (cache tags) and when do you use them? — Tags group related objects for atomic bulk purge—used when a single data change affects many cached pages.
• How does `stale-while-revalidate` differ from setting a longer max-age? — SWR serves stale immediately but fetches fresh in background; longer max-age just delays revalidation without background fetch.
• What CDN invalidation strategy would you use for a high-traffic e-commerce product page? — Discuss short TTL + API purge on inventory change + cache tags per product ID.

Related Questions

• Consistent Hashing
• Rate Limiting
• CDN
• Load Balancer — L4 vs L7
• Distributed Transactions — 2PC, Saga