CDN Strategy and Edge Delivery

The plain-language idea

A CDN (Content Delivery Network) is a set of servers distributed at network points of presence (PoPs) around the world, each capable of serving a cached copy of your content. Instead of every user's request traveling all the way to one origin server (which might be in a single data center on one continent), a nearby PoP answers instead. Less physical and network distance means less round-trip time, which lands directly on TTFB (Time to First Byte, the first sub-part from the LCP-diagnosis lesson) — TTFB is largely a function of how far a request has to travel and back, and a CDN shortens that trip for anyone not already close to the origin.

That's the easy half of the story. CDNs were built for static assets — images, CSS, JS bundles, fonts — content that's identical for every user and safe to cache at the edge indefinitely (or until it changes). The harder half is dynamic or personalized content: a logged-in dashboard, a page with per-user pricing, an API response that differs by request. A PoP can't just cache "the" response, because there isn't one — there's a different correct response per user, per session, per query parameter. Two real approaches handle this: a cache-key strategy that accounts for what actually varies (cache separately per cookie, per auth header, per query param — so requests that are truly identical still hit the shared cache, and only the genuinely-different ones fall through), or edge compute, where small pieces of logic run at the PoP itself and can personalize a response without a full round trip back to origin.

See it in a real thing: a deploy that serves stale content

Say a CDN caches /app.js for 24 hours to avoid re-fetching it from origin on every request. A deploy ships a bug fix to app.js, but for up to 24 hours, some fraction of users still get the old, cached, buggy version at edge PoPs that haven't expired their copy yet — the deploy "worked," but a real slice of users don't see it.

There's a famous, appropriately self-deprecating line about this: there are only two hard problems in computer science — cache invalidation and naming things. Manually purging every PoP's cache the instant you deploy is the naive fix, and it's genuinely hard to get right: it's a network operation with its own latency and failure modes, and a missed PoP means a customer at a "purged" CDN edge still seeing stale content is a hard bug to reproduce.

/app.js               <- cached 24h, ambiguous forever: is THIS copy current?
/app.a1b2c3d4.js       <- filename changes only when content changes

The reliable fix sidesteps invalidation entirely: content-hashed filenames, already a byproduct of most modern build tooling. If the file's contents change, its filename changes (the hash is derived from the content itself), so the URL /app.a1b2c3d4.js refers to one immutable version, forever. You don't invalidate anything — you just point the HTML at a new URL, and that new URL simply hasn't been cached anywhere yet, so every PoP fetches it fresh on first request. The old, hashed file can sit in caches indefinitely without ever being wrong, because nothing ever asks for it to mean something different.

What people usually miss

Watch out

• A CDN doesn't make dynamic, per-user content free to serve fast — static and dynamic are genuinely different problems, and treating "put it behind a CDN" as a universal fix ignores that personalized responses need a cache-key or edge-compute strategy, not just a TTL.
• Cache invalidation is the hard part, not caching itself. Setting a cache header is trivial; guaranteeing every PoP reflects a change at the moment you need it to is the real engineering problem, which is exactly why content-hashing sidesteps it instead of solving it head-on.
• The HTML entry point usually should NOT be long-cached, even when everything it references is. If the HTML itself is stale, it points at old hashed filenames, and the whole cache-busting scheme fails silently — a short or no-cache TTL on the entry HTML is what makes hashed-asset caching actually work.
• Geographic distance isn't the only latency source a CDN helps with — a PoP terminating the TLS handshake close to the user also cuts round trips before any bytes of the response even start moving.

Why this matters in interviews

"A user in Singapore says the site is slow, but it's fast for you in the US — what's going on and what would you check?" is a real diagnostic question, and naming CDN/PoP distance as a TTFB driver, then following it with how you'd actually invalidate a stale deploy safely (hashed filenames, not manual purging), is what separates a surface answer from a working one.