Ecommet
Start a project
Topic 16 of 75

Content Delivery Networks (CDNs)

A CDN keeps copies of your files on servers around the world so users download them from nearby. Learn how pull and push CDNs work, what makes a good cache key, and how to update content safely.

Beginner 6 min read 3 quiz questions

Jump to the quiz

In a nutshell

  • A CDN serves content from edge servers close to users: lower latency and far less load on your origin.
  • Pull CDN: fetches from your origin on the first request and caches it. Push CDN: you upload content ahead of time.
  • Control caching with Cache-Control headers; use fingerprinted file names so new versions never need purging.
  • CDNs also absorb traffic spikes and attacks, and terminate TLS near users.

Why a CDN

The speed of light is fixed. A user in Chennai fetching an image from a server in Virginia waits on a round trip of well over 200 ms, for every file the page needs. A CDN puts copies of those files on servers in hundreds of cities, so the round trip shrinks to a few milliseconds.

Edge servers near users

Edge servers near users Users in Chennai → Edge: Chennai: ~5 ms Users in London → Edge: London: ~5 ms Edge: Chennai → Origin: miss only Edge: London → Origin Users in ChennaiUsers in LondonEdge: ChennaiEdge: LondonOriginyour servers~5 ms~5 msmiss only
Users fetch from the nearest edge. Only cache misses travel to the origin.
Diagram as text
  • Users in Chennai → Edge: Chennai: ~5 ms
  • Users in London → Edge: London: ~5 ms
  • Edge: Chennai → Origin: miss only
  • Edge: London → Origin
  • Faster pages: static files load from a nearby edge.
  • Less load and cost on your servers: most requests never reach them.
  • Resilience: the CDN absorbs traffic spikes and many denial-of-service attacks.
  • TLS at the edge: the encryption handshake happens close to the user, saving round trips.

Pull vs push

Pull CDN: the first request fills the cache

Pull CDN: the first request fills the cache First user → Edge: GET /logo.png Edge → Origin: miss: fetch it Origin → Edge: logo.png, max-age=1 year Edge → First user: logo.png Next user → Edge: GET /logo.png Edge → Next user: hit: from cache First userEdgeOriginNext userGET /logo.pngmiss: fetch itlogo.png, max-age=1 yearlogo.pngGET /logo.pnghit: from cache

All steps The first user in a region pays for the trip to the origin; everyone after them is served from the edge.

Diagram as text
  1. The first user in the region asks the edge for a file.
  2. The edge does not have it yet, so it fetches it from your origin.
  3. The origin returns the file with headers saying how long it may be cached.
  4. The edge stores a copy and serves it.
  5. The next user asks for the same file.
  6. This time the edge answers from its cache without contacting the origin.
Pull CDNPush CDN
How content arrivesFetched from the origin on the first requestYou upload it to the CDN in advance
EffortMinimal: point the CDN at your siteYou manage uploads and updates
First requestSlower (a miss)Fast (already there)
Best forWebsites and APIs with many files that change oftenLarge files that change rarely: videos, installers, game downloads

Controlling the cache

The origin decides what the CDN may cache, and for how long, with HTTP headers:

  • Cache-Control: public, max-age=31536000, immutable for files with a content hash in the name.
  • Cache-Control: public, s-maxage=60 to let shared caches (CDNs) keep a page for a minute.
  • Cache-Control: private or no-store for anything personal: account pages, carts, API responses with user data.

The cache key decides which requests share a cached copy. By default it is usually the URL. Adding needless parts (tracking query strings) splits the cache and lowers the hit rate; leaving out parts that change the response (language, device type) serves the wrong content.

Updating content

Two ways to make users see a new version:

  1. Fingerprinting (best): build tools name files by their content, such as app.3f9a1c.js. A new version gets a new name, the HTML points to it, and the old file can stay cached forever. Nothing needs purging.
  2. Purging: ask the CDN to drop a URL from every edge. Useful for content whose URL cannot change (a product image, an HTML page), but it takes time to spread, and purging everything at once sends all traffic back to your origin.

Common mistakes

  • Caching personalised pages at the CDN.
  • Using the same file name for every release and then fighting stale caches.
  • Including random query parameters in the cache key and getting a near-zero hit rate.
  • Purging everything on each deploy, sending all traffic back to the origin at once.

Interview questions

Try answering out loud before you open each one.

Pull or push CDN for a photo-sharing app?

Pull. There are millions of photos, most rarely viewed; a pull CDN caches the popular ones automatically near the users who request them. Push suits a small set of large, known files such as a game download.

How do you deploy a new JavaScript bundle without users getting a stale one?

Fingerprint file names with a content hash and serve them with a long max-age. The HTML (cached briefly or not at all) references the new name, so browsers and CDNs fetch it as a new file. No purge needed.

Check yourself

1. Where does a pull CDN get a file it does not have yet?
Show the answer

Answer: From your origin server. On a miss, the edge fetches from the origin and caches the result.

2. Which header should a page with a user's account details send?
Show the answer

Answer: Cache-Control: private or no-store. Private data must never be stored in shared caches.

3. What makes fingerprinted file names (app.3f9a1c.js) useful?
Show the answer

Answer: A new version gets a new URL, so old copies never need purging. Content-addressed names let you cache forever and still ship updates instantly.

Further reading

Your notes

Saved in this browser as you type.

Finished this topic?

Mark it read to track your progress, then carry on with the next one.

Next topic