What Is a CDN and How Does It Work?

If your servers live in one data center and your users live everywhere, physics is working against you. A CDN is how you fight back. Let's walk through what it is, why it matters, and how the pieces fit together.

What a CDN is#

A CDN, or content delivery network, is a fleet of servers spread across the globe that store copies of your content close to your users. Each location is a point of presence, or PoP, and the machines inside it are edge servers. Instead of every request traveling all the way to your origin, most get answered by the nearest edge.

Think of it like a chain of local warehouses. Your origin is the central factory, and the CDN keeps popular goods stocked near every city so customers get same-day delivery instead of a shipment from across the country.

Why it matters#

The core problem is distance. Every packet obeys the speed of light, and the round-trip time (RTT) between a user in Sydney and a server in Virginia is real latency you cannot code away. A page load involves many round trips, so that delay stacks up. Serving from a PoP 20 milliseconds away instead of 200 is a night-and-day difference.

Three more payoffs come beyond speed:

Origin offload: When edges answer most requests, your origin handles a fraction of the traffic. That means smaller bills and fewer capacity headaches.

Availability: If your origin hiccups, edges keep serving cached content, and a CDN spreads load so a spike in one region doesn't take everything down.

DDoS absorption: A large CDN has enormous aggregate bandwidth, so attack traffic gets soaked up across hundreds of PoPs instead of drowning your single origin.

How it works#

Here is the flow. A user requests an asset, and anycast routing sends it to the nearest PoP automatically. With anycast, many PoPs advertise the same IP address, and internet routing steers each user to the closest one. Some CDNs layer geo-aware DNS on top, but the effect is the same: you land at the closest edge.

The edge checks its cache:

Cache hit: The edge has a fresh copy and serves it immediately. This is the fast path.

Cache miss: The edge has nothing, or a stale copy. It fetches from your origin, serves the response, and stores a copy for the next visitor. The first person pays the latency cost; everyone after them gets the hit.

What decides whether something is cached, and for how long? Your HTTP response headers. The Cache-Control header is the main lever. Here is a typical static-asset response:

HTTP/1.1 200 OK
Content-Type: image/png
Cache-Control: public, max-age=31536000, immutable

That max-age=31536000 tells the CDN to keep the file for a year, and immutable promises it will never change under that URL. The time-to-live (TTL) is that value counting down. When it hits zero, the edge treats the copy as stale and revalidates with the origin.

You can watch this with curl. Most CDNs add a header telling you whether they served from cache:

$ curl -sI https://example.com/logo.png | grep -i cache
cache-control: public, max-age=31536000
cf-cache-status: MISS

$ curl -sI https://example.com/logo.png | grep -i cache
cache-control: public, max-age=31536000
cf-cache-status: HIT

The first request warmed the edge; the second was served from it. That flip from MISS to HIT is the whole game.

What to cache and what not to#

Static content is the easy win: images, CSS, JavaScript bundles, fonts, and videos. These are identical for every user and change rarely, so a long TTL is safe.

Increasingly, teams cache more than static files. Cacheable API responses (a product catalog, a public price list) and even full HTML pages can live at the edge when they're the same for everyone. This is where big gains hide, since HTML is often the slowest part of a load.

What you should not cache is anything personalized or authenticated. A dashboard, a shopping cart, or any response tied to a login session must never be shared from a public cache. Serving one user's private page to another is a serious data leak. Mark those responses Cache-Control: private, no-store and keep them off the edge.

Cache keys, invalidation, and purging#

How does the edge know whether two requests want the same thing? The cache key. By default it's usually the full URL, but you can tune it to include or ignore query strings, headers, or cookies. Too broad a key serves the wrong content; too narrow a key wrecks your hit rate.

The hard part of caching is getting rid of content on purpose. When you ship a fix, you need the edge to drop its old copy and pull the new one. That's invalidation, also called purging, and the approaches range from versioned filenames to explicit purge APIs. We go deep on this in our CDN cache invalidation strategies post.

Edge compute: the modern extension#

CDNs started as dumb caches. Today they run your code. Platforms like Cloudflare Workers, Fastly Compute, and Lambda@Edge let you execute logic at the PoP, milliseconds from the user. You can rewrite requests, check auth tokens, personalize a cached page, or assemble a response from several sources without ever touching your origin. This turns the edge from a warehouse into a small distributed computer.

The leading CDNs#

Four names dominate. Cloudflare is known for its huge network, generous free tier, and strong Workers platform. Fastly is prized for instant purge and developer-friendly edge compute. Akamai is the veteran with the largest footprint and deep enterprise features. Amazon CloudFront integrates tightly with AWS, a natural pick if you already live there.

When you need a CDN#

You want a CDN when users span regions, when you serve meaningful static content, when traffic spikes threaten your origin, or when you need a shield against attacks. That describes nearly every public-facing site today.

You can skip it if your audience is tiny, local, and entirely behind a login, where almost nothing is cacheable. Even then, the DDoS protection alone often justifies the setup.

The call we'd make#

Put a CDN in front of any public site from day one. The static-asset caching is basically free performance, the origin offload saves money as you grow, and the security posture is worth it on its own. Cache your static assets aggressively, keep authenticated responses off the edge, and get a deliberate invalidation strategy in place before you need it. For how this fits with DNS, routing, and the rest of the stack, see our networking fundamentals guide.