SD notes

Content Delivery Networks (CDN)

Beginner · 6 min read · updated 29 October 2026

Quick answer

What is a CDN in system design?

A content delivery network is a fleet of edge servers spread across many regions that cache copies of a site's content close to users. A user's request goes to a nearby edge instead of the distant origin, which cuts round-trip latency, absorbs traffic the origin would otherwise serve and keeps working when one location fails.

On this page

What a CDN does
How an edge fills: origin pull
Freshness: TTL and revalidation
Cache keys and invalidation
Push vs pull
Interview questions
Common questions

A CDN is a cache that sits in many places at once: copies of your content live on edge servers close to your users.

What a CDN does

Cuts latency: requests travel to a nearby edge, not across the world.
Offloads the origin: most requests are answered from edge caches.
Absorbs spikes and attacks: a large, spread-out fleet soaks up load.
Serves static assets best: images, video, CSS, JS, downloads.

Distance sets a floor that no server tuning removes:

Why a nearby edge is faster: round trips computed from distance

Without a CDN every user fetches from one origin in one region. The distances here are illustrative: 13,000, 6,500, 7,500 km.

0:01 / 0:18Step 1 of 6

Transcript · 6 steps

How an edge fills: origin pull

The first request for a file at an edge is a miss; the edge fetches it from the origin.
The edge stores the copy for as long as Cache-Control allows.
Later requests to that edge are hits and never reach the origin.
Each edge fills on its own, so the origin sees roughly one miss per edge per file.

Origin pull: the first request misses and fills the edge, later ones hit

Users ask the nearest edge for /logo.png. The edge starts with an empty cache.

0:01 / 0:19Step 1 of 7

Transcript · 7 steps

Freshness: TTL and revalidation

Cache-Control: max-age=60 makes a copy fresh for 60 seconds.
A fresh copy is served without asking the origin — even if the origin changed.
An expired copy is revalidated with If-None-Match: <ETag>:
unchanged → 304 Not Modified, no body, fresh again;
changed → 200 with the new file.
The TTL is the trade-off: longer means fewer origin trips but staler content.

TTL and revalidation: fresh copies are served, expired ones are checked

At 0s the first request misses. The edge fetches v1 with Cache-Control: max-age=60 and keeps it fresh until 60s.

0:01 / 0:17Step 1 of 6

Transcript · 6 steps

Cache keys and invalidation

The edge looks copies up by a cache key, by default roughly host + path + query.
Two URLs for the same bytes are two keys — and two origin fetches.
Keep only what changes the response in the key: drop tracking parameters, sort the rest.
To change a cached file:
Versioned URLs (app.3f9c2.js): a new name is a new key; cache old names for a year.
Purge through the CDN's API: works for fixed URLs, but takes time to reach every edge.

Cache keys: the same file under two keys is fetched twice

The edge looks each request up by its cache key. /a.png?w=200 is new under both keys, so both miss and fetch from the origin.

0:01 / 0:18Step 1 of 6

Transcript · 6 steps

Push vs pull

	Pull CDN	Push CDN
How content arrives	Edge fetches on first miss	You upload ahead of time
First request	Slower (a miss)	Fast
Effort	Point the CDN at the origin	Manage uploads and deletes
Fits	Most websites, changing assets	Large, rarely changing files

Never cache personal responses on a shared edge: send Cache-Control: private or no-store.
DNS or anycast routing sends each user to a nearby edge — see DNS.

Interview questions

What would you put on a CDN? Static assets and media; shared API responses only with short TTLs.
How do you deploy a new version of a cached file? Use content-hashed file names so a deploy changes the URL; purge only what has a fixed URL.
What is a cache hit ratio and why does it matter? The share of requests answered at the edge; every miss is origin load and a slow response.
Why did users still see the old file after a deploy? It was fresh by its TTL at the edges (and maybe in browsers); purge it or version the URL.

Next: Database Replication · Before this: Caching

Common questions

How does a CDN reduce latency?

Every round trip costs time proportional to distance, and a first HTTPS request needs several of them. An edge a few hundred kilometres away answers the handshakes and serves the cached file, so the user never waits on a round trip to the far origin.

What is the difference between a push CDN and a pull CDN?

A pull CDN fetches a file from the origin the first time an edge is asked for it and caches it from then on. A push CDN has you upload content to the CDN ahead of time. Pull needs no upload step; push suits large files that change rarely and must never miss.

What happens when the TTL of a cached file expires?

The edge does not throw the copy away. It revalidates: it asks the origin with If-None-Match or If-Modified-Since, and the origin answers 304 Not Modified with no body if nothing changed, or 200 with the new file if it did.

How do you update a file that a CDN has cached?

Either purge it through the CDN's invalidation API, which takes effect across edges after a short delay, or give each version a new URL such as app.3f9c2.js. Versioned URLs let you cache for a year and change instantly, because a new name is a new cache key.

Can a CDN cache dynamic or personalised pages?

Shared responses can be cached for seconds, which still absorbs bursts. Anything personal must be marked private or no-store so an edge never serves one user's page to another. CDNs still help dynamic traffic by terminating TLS near the user and keeping warm connections to the origin.

CDN in System Design: Edges, TTLs and Origin Pull

How a CDN works for system design interviews: edge servers, origin pull, TTL and revalidation, push vs pull and cache keys, with looping animations.

Subject: System Design
Level: Beginner
Reading time: 6 min
Updated: 2026-10-29

What is a CDN in system design?

A CDN is a cache that sits in many places at once: copies of your content live on edge servers close to your users.

What a CDN does

Cuts latency: requests travel to a nearby edge, not across the world.
Offloads the origin: most requests are answered from edge caches.
Absorbs spikes and attacks: a large, spread-out fleet soaks up load.
Serves static assets best: images, video, CSS, JS, downloads.

Distance sets a floor that no server tuning removes:

Why a nearby edge is faster: round trips computed from distance.

Without a CDN every user fetches from one origin in one region. The distances here are illustrative: 13,000, 6,500, 7,500 km.
Light in fibre covers about 200 km per millisecond, so a round trip takes at least 2 × distance ÷ 200: 130, 65, 75 ms, before the server does any work.
A first HTTPS request needs about 3 round trips (TCP, TLS 1.3, the request), so the farthest user waits at least 390 ms on distance alone.
A CDN places edge servers near users and serves cached copies from them. Each user now talks to an edge a few hundred kilometres away.
The round trip to the edge is at least 4, 3, 6 ms. The handshakes happen with the edge too, not with the far origin.
Three round trips now cost 12, 9, 18 ms instead of 390, 195, 225 ms, as long as the edge already holds the file.

How an edge fills: origin pull

The first request for a file at an edge is a miss; the edge fetches it from the origin.
The edge stores the copy for as long as Cache-Control allows.
Later requests to that edge are hits and never reach the origin.
Each edge fills on its own, so the origin sees roughly one miss per edge per file.

Origin pull: the first request misses and fills the edge, later ones hit.

Users ask the nearest edge for /logo.png. The edge starts with an empty cache.
Request 1 reaches the edge, whose cache is empty: a miss. The edge has nothing to serve yet.
On a miss the edge pulls the file from the origin itself. This is an origin-pull CDN: nothing is uploaded ahead of time.
The origin's answer comes back through the edge, which stores a copy for as long as its Cache-Control allows (max-age=3600 here).
Request 2 reaches the edge and finds /logo.png in its cache: a hit. The edge answers at once and the origin is not asked.
Request 3 hits as well, while request 2 has already been answered from the edge in one short round trip.
3 requests, 1 origin fetch, 2 hits: once a file is cached, the origin only sees the first request per edge until the copy expires.

Freshness: TTL and revalidation

Cache-Control: max-age=60 makes a copy fresh for 60 seconds.
A fresh copy is served without asking the origin — even if the origin changed.
An expired copy is revalidated with If-None-Match: <ETag>:
unchanged → 304 Not Modified, no body, fresh again;
changed → 200 with the new file.
The TTL is the trade-off: longer means fewer origin trips but staler content.

TTL and revalidation: fresh copies are served, expired ones are checked.

At 0s the first request misses. The edge fetches v1 with Cache-Control: max-age=60 and keeps it fresh until 60s.
At 30s the copy is still fresh, so the edge serves it without asking the origin.
At 75s the copy has expired. The edge asks with If-None-Match; the origin answers 304 Not Modified, no body, and the copy is fresh until 135s.
At 100s a deploy changes the file to v2 on the origin. The edge does not know: its copy of v1 is fresh until 135s.
At 120s the copy is still fresh by its TTL, so users get v1 although the origin has v2. The TTL bounds how stale content can get.
At 150s the copy has expired again. This time the ETag no longer matches, so the origin sends 200 with v2 and users see the new file.

Cache keys and invalidation

The edge looks copies up by a cache key, by default roughly host + path + query.
Two URLs for the same bytes are two keys — and two origin fetches.
Keep only what changes the response in the key: drop tracking parameters, sort the rest.
To change a cached file:
Versioned URLs (app.3f9c2.js): a new name is a new key; cache old names for a year.
Purge through the CDN's API: works for fixed URLs, but takes time to reach every edge.

Cache keys: the same file under two keys is fetched twice.

The edge looks each request up by its cache key. /a.png?w=200 is new under both keys, so both miss and fetch from the origin.
/a.png?w=200&utm_source=mail is a new string, so the full-URL key misses. Dropping the tracking parameter and sorting gives /a.png?w=200, already cached: a hit.
/a.png?w=400 asks for a different size, so it is a new object under either key and both miss.
/a.png?utm_source=ad&w=200 is a new string, so the full-URL key misses. Dropping the tracking parameter and sorting gives /a.png?w=200, already cached: a hit.
/a.png?w=400 was seen before, so both policies hit.
Same 5 requests: 4 origin fetches with the raw URL as key, 2 with a normalised key. Keep in the key only what changes the response.

Push vs pull

	Pull CDN	Push CDN
How content arrives	Edge fetches on first miss	You upload ahead of time
First request	Slower (a miss)	Fast
Effort	Point the CDN at the origin	Manage uploads and deletes
Fits	Most websites, changing assets	Large, rarely changing files

Never cache personal responses on a shared edge: send Cache-Control: private or no-store.
DNS or anycast routing sends each user to a nearby edge — see DNS.

Interview questions

What would you put on a CDN? Static assets and media; shared API responses only with short TTLs.
How do you deploy a new version of a cached file? Use content-hashed file names so a deploy changes the URL; purge only what has a fixed URL.
What is a cache hit ratio and why does it matter? The share of requests answered at the edge; every miss is origin load and a slow response.
Why did users still see the old file after a deploy? It was fresh by its TTL at the edges (and maybe in browsers); purge it or version the URL.