When shipping a change, would you rely on purging the CDN or on serving the new content under a new URL? Explain when a CDN purge is genuinely the right tool and what it costs.
answer
- invalidation is a distributed problem
- a new URL has nothing to invalidate
- old and new must coexist mid-deploy
- purge propagates, it is not atomic
- browsers ignore your purge entirely
basics
~20 sPrefer new URLs: a new URL is a new cache object, so there is nothing to invalidate and no propagation window. Purge is for content whose URL cannot change — the HTML entry point, feeds, API responses, a mistake you must retract — and it costs propagation delay plus an origin load spike.
solid answer
~50 sDefault to versioned URLs. If the content changes, the URL changes, so the edge simply has never seen the new object and there is no invalidation problem at all — and old and new can coexist safely during a rolling deploy, which matters because users already holding the old page will still request the old files. Purge is the tool for URLs you cannot version: the HTML document at `/`, a feed, an API response, or content you must retract immediately. Its costs are real: a purge has to reach every location, so it is not atomic and there is a window where different users see different versions; a broad purge empties the cache and turns every following request into an origin miss at once. Mitigate with tag-based purge to invalidate a related set instead of everything, and with a soft purge that marks entries stale so the edge keeps serving them while it revalidates.
go deeper
Know that a cache stores content per URL, so publishing under a new filename means the CDN has nothing old to serve, whereas purging is an explicit instruction to forget what it has.
Explain why versioned URLs remove the invalidation problem, why old and new versions must coexist during a deploy, and what a purge cannot reach — anything already sitting in a browser or an intermediate cache.
Show the operational side: propagation is not atomic, a broad purge stampedes the origin, and tag-based or soft purge exist precisely to bound that. Say which content in your system genuinely needs purge at all.
Set the policy: which addresses are versionable, what invalidation authority teams get, and how deploys avoid taking a runtime dependency on a purge API — so a bad release is recoverable without a fleet-wide cache flush at peak.
## The two ways to change what users get **Change the URL.** The new content lives at a new address, so no cache anywhere needs to be told anything. Caches are keyed by URL; a URL nobody has requested before cannot be stale. **Invalidate the URL.** Tell the CDN to drop what it has stored so the next request refetches from the origin. The first is a property of your build and deploy; the second is a distributed operation you run against someone else's fleet. That difference is the whole answer. ## Why versioned URLs win as the default - **There is no invalidation window.** No propagation, no partial state, no waiting. - **Old and new coexist.** During a rolling deploy — and for as long as a user keeps an already-loaded page open — requests for the old files keep arriving. If you had purged and replaced them in place, those requests would get the new bytes, and a page built against the old code would break. Distinct URLs make that impossible by construction. - **It reaches caches you do not control.** A purge only touches the CDN. It does not touch the user's browser cache, a corporate proxy, or an ISP cache. An asset a user already holds under a long lifetime stays there until it expires or is evicted, regardless of what you purge at the edge. This is the single strongest argument for versioning, and it is the point candidates most often miss. - **It makes long lifetimes safe.** Because the URL is a promise about the content, you can hold the object at the edge and in browsers indefinitely. ## When purge is genuinely required Versioning only works where *you* control the address of the thing. It does not work for: - The HTML entry point. `https://example.com/` is the URL users typed and search engines indexed; it cannot become `/index.8f3a1c.html`. - API responses, feeds, sitemaps and other stable, externally referenced addresses. - An image or document already linked from elsewhere, where changing the URL would break inbound links. - Retractions: wrong pricing, a leaked draft, content that must come down now. Waiting for a lifetime to expire is not an option, and this is exactly what purge exists for. A common, healthy design uses both: immutable versioned URLs for assets with long lifetimes, and a short-lived cached document that names them — so a deploy needs at most one small invalidation, or none at all if the document's lifetime is already short. ## What purge costs **It propagates, so it is not atomic.** The instruction has to reach every cache in the fleet. It is usually quick, but during the window some locations serve the old copy and others the new — which is fine for a typo fix and not fine for a change that must be consistent with a simultaneous backend change. **It concentrates load on the origin.** Purging everything empties the cache, so every subsequent request is a miss at the same instant. That is a stampede, and it arrives at whatever traffic level you happen to be at, which is why purging broadly at peak is a bad habit. Two mitigations exist and are worth naming: - **Tag-based purge.** Responses are labelled with keys or tags at the origin, and you invalidate by tag — every page featuring one product, say — rather than by URL list or by everything. Support and header names vary by provider, but the capability is common. - **Soft purge.** Instead of deleting entries, mark them stale. The edge keeps serving the stale copy while it fetches a fresh one in the background, so users never wait and the origin sees a trickle of revalidations rather than a wall of misses. **It is an operational dependency.** A deploy that must call a purge API to be correct now fails when that API is slow, rate-limited or partially applied. A deploy that just publishes new filenames has no such dependency. ## The interview answer Say the default (version the URL, because it removes the problem instead of solving it), say what versioning cannot cover (addresses you do not control, and retractions), and show you know the costs of purge — non-atomic propagation, an origin load spike, a runtime dependency in your deploy — plus the two tools that blunt them. Candidates who say "we just purge everything after each deploy" are describing the habit this question is designed to find.
- Why can old and new asset versions both be needed at the same time during a deploy?Because a user may already be holding a page built against the previous release, and it will keep requesting the files it references — as will anyone still routed to an old server during a rolling deploy. Distinct URLs let both sets be served correctly at once; replacing bytes in place under one URL would hand the old page files it cannot use.
- How would you invalidate every page that features one product, without purging the whole cache?Tag the responses. The origin labels each cached response with keys identifying what it contains — the product id, for instance — and you then purge by that tag, so exactly the affected pages drop out and everything else keeps serving. It avoids both a fragile list of URLs and the origin spike of a full purge.
- A purge went through, but some users still report old content. What are the likely explanations?Their browser is serving its own cached copy, which no edge purge can reach; an intermediate proxy or the user's ISP holds a copy; the purge has not yet reached every location; or the page they are on was itself cached and still references the old URLs. Check what the client actually requested before blaming the CDN.
saying these in an interview costs you the question
- Purging the whole CDN cache after every deploy
- Believing a purge also clears users' browser caches
- Assuming a purge takes effect everywhere instantly
- Replacing asset bytes in place under an unchanged URL
- Making a deploy depend on a purge API call succeeding