The problem: distance
All of Snip's servers are in one datacenter in Virginia. For a user in Sydney, every round trip crosses the Pacific and back, taking on the order of 200 ms, and no faster server can change that: it's the speed of light in fibre (01.04 Numbers to know).
Opening Snip's dashboard takes several round trips before anything appears: one to set up the connection, one or two for encryption, one for the HTML, then more for the scripts, styles and images it refers to. From Sydney, that adds up to a second or more of waiting. Meanwhile, most of the bytes are static files, identical for every user: the JavaScript bundle, the CSS, the logo, the fonts.
A CDN
A CDN (content delivery network) is a large set of servers, called edge servers, spread across many cities. Each one keeps copies of files, and users are sent to one close to them. Snip's own servers become the origin: the place the CDN fetches a file from when it doesn't have it yet.
6 messages. Use Next and Back to follow them in order.
Text version
- User A → Edge (Sydney): GET /app.3f9a.js — User A's browser is sent to the nearby Sydney edge, a few milliseconds away.
- Edge (Sydney) → Origin (Virginia): GET /app.3f9a.js — The edge doesn't have the file yet (a miss), so it fetches it across the Pacific.
- Origin (Virginia) → Edge (Sydney): 200 + Cache-Control (reply) — The origin sends the file with headers saying how long it may be kept. The edge stores it.
- Edge (Sydney) → User A: 200 (reply) — User A pays the long round trip once.
- User B → Edge (Sydney): GET /app.3f9a.js — Later, User B asks for the same file.
- Edge (Sydney) → User B: 200 (hit) (reply) — The edge answers from its copy in a few milliseconds. The origin never hears about it.
That gives Snip three things at once:
- Speed for users far from Virginia: most files come from a few milliseconds away.
- Less load on the origin: it serves each file once per edge, not once per user.
- A shield. CDNs are built to absorb huge traffic spikes, including attacks, before they reach the origin.
Headers decide what's cached
The CDN keeps what your responses tell it to keep, through the Cache-Control header. Snip uses three rules:
| Response | Header | Why |
|---|---|---|
Scripts, styles, images with a fingerprint in the name (app.3f9a.js) | public, max-age=31536000, immutable | The name changes whenever the content does, so a copy can be kept for a year. |
| The HTML page | no-cache (keep it, but check with the origin first) | It names the current script files, so it must always be fresh. |
| A logged-in dashboard or anything personal | private, no-store | Never keep one user's data where another user could be served it. |
The first row is the key trick. Instead of asking the CDN to throw away old copies when you deploy (slow, and
easy to get wrong), you give every new version a new file name. The new HTML points at app.8c21.js, which no
edge has yet, so they all fetch it. The old file can stay cached forever; nobody asks for it anymore.
Should the edge serve redirects too?
Snip's busiest traffic isn't files; it's redirects. Could the CDN cache those, so a Sydney redirect never crosses the
Pacific? It can, with a Cache-Control header on the 302. That's the same trade-off as the 301 in 01.06 Trade-offs: there is no best design:
clicks answered at the edge never reach Snip, so click counts would have to come from the CDN's logs instead. Some CDNs
also run small programs at the edge that could look the code up and record the click there.
Snip keeps redirects at the origin for now: its requirement is 50 ms at the server, the cache from 02.04 Read replicas and a cache already meets it, and accurate counting matters more than the last 100 ms for distant users. It's a reasonable next step if Snip goes global, and a good one to mention in an interview.
ChangeStatic files are served from edge servers near users
Text version
Change: Static files are served from edge servers near users
Added: CDN edge.
New connections: Browser → CDN edge (files); CDN edge → Snip app (on miss).
What a CDN costs
- Money per gigabyte served, on top of what you already pay.
- Staleness. Anything cached at the edge is out of your hands until it expires. Fingerprinted file names avoid most of the pain.
- Leaks, if headers are wrong. Caching a personalised page at the edge can show one user's data to others. Mark
anything personal
private. - Harder debugging. "It works for me" can mean you and the user hit different edges with different copies.
Seen in production
Netflix
2016Open Connect
Netflix decided in 2011 to build its own CDN, Open Connect. By 2016 it had appliances in close to 1,000 locations, many inside internet providers' own networks, and it delivered 100% of Netflix's video traffic. New files are copied across oceans once, during off-peak hours, then replicated to servers within each provider, with popularity models deciding which files go where.
What we foundAt big enough scale, a company can build its own CDN and place the edge servers inside internet providers' networks.
How Netflix works with ISPs around the globe to deliver a great viewing experienceabout.netflix.com ↗Snip deploys a new design, but many users still see the old styles hours later. The stylesheet is served as /styles.css with max-age=86400 (one day). What's the best fix?
Recap
Interview questions
What is a CDN, and what would you put on one?