CDNs

A Content Delivery Network (CDN) is a globally distributed set of cache servers that store copies of your content close to users. It is one of the simplest and highest-impact scaling levers you can propose, because it cuts latency, offloads your origin servers, and reduces bandwidth cost all at once.

Why It Matters: Physics

Latency is bounded by the speed of light. A user in Sydney hitting an origin in Virginia pays a round trip of roughly 200 milliseconds or more per request, and a page needs many requests. A CDN edge location (a Point of Presence, or PoP) in Sydney answers in single-digit milliseconds. You cannot make light faster, so you move the content closer to the user.

How a CDN Works

• A user request is routed (via anycast or GeoDNS) to the nearest healthy PoP.

• On a cache hit, the PoP serves the content directly. Fast, and your origin never sees the request.

• On a cache miss, the PoP fetches from the origin (or a regional shield/parent cache), stores a copy, and serves it. Later requests for the same content are hits.

• The cache key is usually the host plus path plus a chosen set of headers and query params. A Time To Live (TTL) controls how long a copy is considered fresh.

Pull vs Push

A pull CDN fetches from the origin on the first miss and is the common default (you just point it at your origin). A push CDN has you upload content ahead of time and is useful for large files you want pre-positioned, like video-on-demand libraries.

What to Cache

• Static assets: images, JavaScript, CSS, fonts, and video segments. These are the biggest, easiest wins.

• Cacheable dynamic content: GET API responses or rendered HTML that is safe to serve to many users, with a carefully chosen cache key.

• Immutable assets: give files content-hashed names (app.a1b2c3.js) and a long TTL, so a new deploy simply changes the URL rather than needing an invalidation.

Cache Control and Invalidation

You control freshness with HTTP headers: Cache-Control max-age and s-maxage set TTLs, no-store disables caching, private marks user-specific responses, and stale-while-revalidate serves a slightly stale copy while refreshing in the background. When content changes early, you invalidate: either purge the object explicitly or, better, change the URL (versioning) so the old copy is simply never requested again. Cache invalidation is famously one of the hard problems, so lean on TTLs and versioned URLs rather than manual purges.

Beyond Static Files

Modern CDNs do more than cache: TLS termination at the edge, origin shielding to protect your origin from a flood of misses, signed URLs and tokens for private content, DDoS and WAF protection, and edge compute (Cloudflare Workers, Lambda@Edge) to run logic close to users. Track cache hit ratio as your key health metric; a low hit ratio means you are not getting the benefit.

When Not to Cache at the Edge

Highly personalized responses (a logged-in user's private dashboard) or rapidly changing data without a safe cache key should not be cached publicly, because you risk serving one user's data to another. For those, use short micro-caching, cache only the shared fragments, or assemble the response at the edge.

Common Mistakes

• Caching personalized or authenticated responses publicly, leaking data between users.

• Putting cookies or volatile query params in the cache key, which shatters the hit ratio.

• Having no invalidation or versioning strategy, so stale content lingers.

• Forgetting to mention the CDN at all when the design is clearly read-heavy on static content.

Interview Soundbite

"The static assets and these cacheable read responses go behind a CDN with content-hashed URLs and long TTLs, which cuts user latency to single-digit milliseconds and takes the bulk of read traffic off the origin. Personalized responses stay dynamic, and I will watch the cache hit ratio."