CDN Fundamentals

A CDN — short for content delivery network (also called a content distribution network) — is a globally distributed network of edge servers (points of presence, or PoPs) that caches content close to users to reduce latency, offload origin traffic, and help absorb load spikes or attacks.

From the user's perspective, a CDN is invisible — they just request a URL and get a fast response. Behind that URL, a network of edge servers at points of presence (PoPs) sits between the user and the origin server that owns the content. By serving cached objects from nearby PoPs, the CDN cuts latency, offloads repeat traffic from the origin, and helps prevent global demand from concentrating on one backend tier.

The core responsibilities

Every CDN story starts the same way: a user far from the origin, and a slow, expensive network trip.

The distance problem

Network latency has a hard physical floor — the speed of light over fiber. A user in Mumbai requesting content from a server in Virginia pays a real, unavoidable round-trip cost — roughly 130 ms just for light in fiber over ~13,000 km (illustrative: 2 × 13,000 km ÷ 200,000 km/s), and commonly 200 ms or more once routing and queueing are included — no matter how fast the origin server itself is. You can't optimize your way out of geography with a faster CPU.

Not just speed — survival

The second motivation is just as important: a single origin is a single point of load. If a piece of content goes viral, every single request would otherwise hit that one server. A CDN turns "thousands of requests hitting the origin" into "one request hits the origin, thousands are served from cache" — protecting the origin from traffic it was never provisioned to handle.

An edge location (or point of presence — PoP) is a small data center that sits geographically close to a group of users and holds a partial cache of origin content.

A large CDN operator runs hundreds of PoPs across the globe. Each PoP has its own edge cache, so the first request in one region can still miss even if another region is warm. Many CDNs add mid-tier caches or origin-shield layers behind those PoPs, so some misses are satisfied inside the CDN before they ever reach the origin.

Every request that reaches an edge location results in either a cache hit (served instantly) or a cache miss (fetched from origin first, then cached).

Worked trace: MISS, then HIT (illustrative)

The copy stays fresh while age < max-age, so this one has 3,600 − 40 = 3,560 s left; after that the edge revalidates (conditional request) or refetches. Hit-ratio arithmetic (illustrative): with 10,000 requests/s reaching the edge, origin load = total × (1 − hit ratio): a 90% hit ratio sends 1,000 req/s to the origin, 95% sends 500 req/s, and 99% sends 100 req/s. Small hit-ratio gains therefore cut origin load by large factors.

Time-to-live (TTL) determines how long a cached object is considered fresh before the edge must re-check the origin.

TTL is usually set via HTTP response headers — most commonly Cache-Control: max-age=<seconds> or the older Expires header. Once the TTL elapses, the object is considered stale; the next request typically triggers a revalidation or a fresh fetch from the origin, depending on the cache directives and whether validators like ETag or Last-Modified are available.

Sometimes you can't wait for a TTL to expire — cache invalidation (purging) forcibly removes a stale object from edge caches immediately.

Invalidation is typically triggered by a deployment pipeline right after publishing new content — "purge /app.js and /styles.css" — so users don't have to wait out a long TTL to see the update. Most CDNs support purging by exact URL, by tag/surrogate-key, or by wildcard pattern.

Not everything can — or should — be cached. Understanding what's cacheable is central to designing with a CDN.

Cache-Control tells caches whether a response may be stored and reused; the cache key decides which requests are allowed to share that stored object.

By default, most CDNs build a cache key from the request path plus (often) the full query string. Two requests differing only by ?color=red vs ?color=blue are treated as separate objects unless configured otherwise. CDNs let you customize the key — ignore tracking parameters, include selected headers such as Accept-Language, or vary on tightly scoped cookies when the response truly changes.