Your team ships a new JS bundle under the same URL /app.js on every deploy, and users keep complaining they're stuck on stale versions after a release even though the file changed on the server. What CDN caching mistake is likely happening, and how would you fix Cache-Control and the deployment strategy to solve it for both this JS bundle and images that rarely change?

## What Cache-Control declares `Cache-Control` is the HTTP response header the origin uses to tell every downstream cache — the browser, the CDN edge, and any intermediate shield — how long a response may be reused and under what conditions. The **key directives** are: | Directive | What it does | |---|---| | `max-age` | seconds a response is fresh for, honored by all caches including the browser | | `s-maxage` | overrides `max-age` specifically for shared/proxy caches like a CDN edge, letting you cache longer at the edge than in an individual browser | | `no-cache` | may be stored, but must be revalidated with the origin, typically via a conditional request, before each reuse | | `no-store` | must never be stored at all, used for genuinely sensitive responses | | `must-revalidate` | once stale, don't serve it even if the origin is unreachable — fail rather than serve outdated content | | `immutable` | a newer addition telling caches this exact URL will never change, so skip revalidation entirely even on a user-initiated refresh | Together these directives form a contract: the origin declares how stale a response is allowed to get before every cache layer must refresh it. ## Why the extra machinery exists The reason this machinery exists is that TTL-based expiry alone can't cover every situation. A long TTL is great for performance and origin offload, but it means an edit at the origin doesn't show up until the TTL lapses everywhere it's cached. Two complementary strategies solve this: 1. **Versioned (cache-busting) URLs** — embedding a content hash or build version in the filename, so the filename itself changes whenever the bytes do — sidestep the staleness problem entirely for build assets like JS/CSS/images: because a changed file is a brand-new URL, there's no old cached copy to invalidate, and the old URL's cached copy simply becomes irrelevant and ages out naturally. This is the standard pattern used by modern bundlers (webpack, Next.js, Vite) and is why static asset distribution through a CDN pairs so naturally with `immutable`, far-future `Cache-Control` headers — a year-long `max-age` is safe precisely because the URL is guaranteed content-addressed. 2. **Manual purge/invalidation** — when content isn't naturally versioned this way — a CMS-authored article page, for instance, still living at a stable canonical URL — purging is the tool. The one piece that can't be content-hashed, the entry point that references the current hash (an HTML page, a JSON manifest, or an app-shell file), instead gets a very short or zero TTL so that clients always discover the latest hash quickly, cascading the correct freshness down to a single small, cheap-to-refetch file. Both browsers and CDNs also support `stale-while-revalidate`, which lets a cache serve the (now slightly expired) cached copy immediately while asynchronously refetching a fresh copy in the background for the next request, hiding origin latency from the user at the cost of occasionally serving content a few seconds out of date. ## The central trade-off The central trade-off is between long TTLs plus explicit invalidation versus short TTLs: - **Long TTLs plus explicit invalidation** — fast for most requests, but stale until someone remembers to purge or the content is content-addressed. - **Short TTLs** — always close to fresh, but a constant trickle of origin traffic even when nothing changed, since every PoP re-checks or re-fetches far more often. Purging itself isn't free either: propagating an invalidation instruction to every edge PoP in a global fleet isn't instantaneous, and firing broad purges frequently is rate-limited and can trigger a correlated burst of cache misses back to origin. ## Failure modes - **The most common failure mode in practice** is exactly the one in this scenario: treating a mutable, frequently-changing URL as if it were `immutable` by giving it a long `max-age`, so the CDN and every user's browser happily keep serving bytes from three deploys ago. - **A more dangerous variant** of the same mistake is applying a public, long `max-age` to a response that actually contains personalized or sensitive data — a shared cache will then serve one user's private response to a different user requesting the same URL, an actual data leak rather than just a staleness bug. Both are fixed by matching the `Cache-Control` policy to how the URL actually behaves: `immutable` and long-lived only for genuinely content-addressed assets, short-lived or private for anything that varies per request or per user.