Content Delivery Network

A CDN caches content at edge locations close to users. It cuts latency and origin load, but introduces cache keys, invalidation, and consistency decisions.

networking

Definition

A content delivery network (CDN) is a geographically distributed set of reverse proxies that cache responses and terminate connections near end users, reducing latency, absorbing traffic spikes, and shielding origin servers from direct load.

Context and scope

CDNs serve static assets, API responses, and media, and increasingly run edge compute. Correct behavior depends on cache keys, TTLs, revalidation with ETags, and a deliberate invalidation strategy.

Common misconceptions

A CDN makes every response faster, including uncacheable ones
Purging a URL removes the content everywhere instantly
Cached content is private because it sits behind your domain

Anti-patterns

Caching personalized or authenticated responses without private directives
Using one short TTL for immutable, content-hashed assets
Assuming origin changes appear at the edge immediately

Related concepts

Related examples

Authoritative source

https://developer.mozilla.org/en-US/docs/Glossary/CDN

How it works

A CDN routes each request to a nearby point of presence using DNS or anycast, then looks up a cache key built from host, path, query string, and selected headers. On a miss it fetches from the origin, stores the response according to Cache-Control, and revalidates with ETags when stale. Modern edges also terminate TLS, compress, and run limited compute.

Cache-Control: public, max-age=31536000, immutable   # hashed asset
Cache-Control: public, max-age=60, stale-while-revalidate=30
Cache-Control: private, no-store                     # account page

When to use it

Use a CDN for static assets, media, public API reads, and audiences spread across continents. It absorbs traffic spikes and shortens the network path. Compared with a single origin behind a load balancer, a CDN adds geographic distribution and caching but also another layer whose state must be understood and observed.

Trade-offs

Higher hit ratios mean staler content; short TTLs mean more origin traffic. Purging is rate-limited, may take seconds to minutes, and does not reach every cache instantly. Personalized responses need private or no-store and careful Vary handling. Debugging requires cache-status headers and origin logs, while edge and egress pricing vary by provider.

Concrete example

A team deploys app.9f2c.js with a one-year immutable TTL, so browsers and edges never revalidate it. They purge HTML entry points by cache tag after each release. A misconfigured API rule caches JSON for an hour, showing why authenticated responses need private and why purge drills matter.

A CDN does not automatically speed up dynamic, uncacheable requests, and a purge is not guaranteed to be instantaneous globally. Cached content is not private just because it is on your domain. Related concepts include ETag, HTTP Caching, Cache Invalidation, DNS, and Cache Stampede.