How CDNs Work

A content delivery network (CDN) is a network of servers spread across many locations that caches copies of your content close to users. When someone requests an image, script or page, the nearest edge server answers from its cache if it can, and only fetches from your origin server when it has to. The result is lower latency for users, far less traffic on your origin and better resilience during spikes.

The basic flow

1. A user requests https://example.com/app.js.
2. Routing sends the request to a nearby edge location (a point of presence, or PoP).
3. The edge checks its cache using the request’s cache key.
4. Cache hit: it returns the stored copy immediately.
5. Cache miss: it fetches from the origin (or a regional tier), returns the response and stores it for next time, if the headers allow.

How requests find the nearest edge

• DNS-based routing: the CDN’s DNS answers with the address of a nearby, healthy edge.
• Anycast: many locations announce the same IP address, and internet routing carries each user to a nearby one.

Inside each location, load balancers spread requests across many cache servers; our guide to load balancing algorithms covers the techniques.

What decides caching: headers

HTTP caching rules (RFC 9111) let your origin tell the CDN and browsers what to do:

Revalidation saves bandwidth: with an ETag or Last-Modified header, the edge can ask the origin “has this changed?” and receive a tiny 304 Not Modified response instead of the full file.

Cache keys

The cache key decides which requests share a cached copy. By default it’s usually the URL. Adding query strings, headers (via Vary) or cookies to the key makes caching more precise but splits traffic into more variants and lowers the hit ratio. A classic mistake is caching a page that varies by cookie under a key that ignores cookies, which can show one user’s content to another. Never cache personalised responses in a shared cache.

Updating content: invalidation and versioning

• Versioned file names: include a content hash in the file name (app.3f9a1c.js) and cache for a year. A new deploy produces a new name, so there’s nothing to purge.
• Purge or invalidation: tell the CDN to drop specific URLs or tags. Useful for HTML and content that keeps its URL.
• Short TTLs plus stale-while-revalidate for content that changes often but can be a few seconds old.
• Soft purges, where offered, mark content stale instead of deleting it, so the edge can keep serving the old copy while it fetches the new one.

The same trade-offs between freshness and load appear in application caches; see our caching strategies guide.

Origin shielding and tiered caching

With hundreds of edge locations, a popular file that expires everywhere at once could send hundreds of requests to your origin. Origin shielding (or tiered caching) routes misses through a regional mid-tier cache, so the origin sees one request instead of many. It also protects the origin during a cold start after a purge.

Dynamic content

CDNs help even with content they can’t cache:

• Connection reuse between edge and origin avoids repeated TLS handshakes over long distances.
• TLS termination at the edge shortens the slowest part of the handshake for users.
• Route optimisation across the CDN’s own network.
• Micro-caching: caching dynamic pages for a second or two can absorb huge spikes.

Security and edge features

• DDoS absorption: a large, distributed network soaks up floods that would overwhelm one origin.
• Web application firewalls block common attack patterns before they reach you.
• Edge rate limiting stops abusive clients early; the algorithms are the same as in our rate limiting guide.
• Edge compute: small functions that run at the edge for redirects, headers, authentication checks or A/B tests.

Where CDNs fit in system design

Any design with heavy media or static assets, such as a news feed, should serve them through a CDN from object storage. Measure the cache hit ratio, origin bandwidth and latency by region; a falling hit ratio usually means a cache key or header problem. Watch what you send to the edge, too: oversized images and missing compression are common reasons a CDN-backed site still feels slow.

Frequently asked questions

Does a CDN help if my users are in one country?

Often yes. It still offloads your origin, absorbs spikes and attacks, and terminates TLS closer to users, even within one country.

Can a CDN cache API responses?

Yes, for public, non-personalised responses with appropriate Cache-Control headers. Personalised or authenticated responses should not be cached in shared caches.

What is a good cache hit ratio?

It depends on your content. Sites with mostly static assets often see very high ratios; sites with lots of dynamic or personalised pages see lower ones. Track the trend and investigate sudden drops.