What is a CDN?
A CDN (content delivery network) is a chain of caches rented by city: hundreds of small server sites around the world — called edges — that each keep copies of your files close to the people asking for them. Your servers (the origin) stay in one place; the copies travel.
It exists because of physics, not software. Data moves through cables at a large fraction of the speed of light and STILL needs ~200 milliseconds to make the round trip from Sydney to Virginia. No code optimization fixes geography — the only cure is moving the bytes closer before they are asked for.
CDNs shine for static content: files that are the same for every user — images, videos, CSS, fonts, app bundles. One copy serves everyone in a city, so caching it at the edge pays off instantly.
- edge (PoP)
- — a small CDN server site in one city, holding copies
- origin
- — your real servers/storage — the source the edges copy from
- static content
- — files identical for every user: images, CSS, videos
Words to know
Sydney thinks the app is broken
SliceNow expands to Australia. The servers live in Virginia, and every menu page shows twelve appetizing pizza photos of about 500KB each. For a Sydney customer, EVERY photo crosses the Pacific: ~200ms of round trips per file plus the transfer itself — the menu takes 6 seconds to finish loading. Reviews say 'app feels broken'.
Here is the waste: those twelve photos are identical for every customer in Sydney. The same bytes crossed the Pacific thousands of times yesterday. This is exactly the cache condition from two lessons ago — the same question asked again and again — just at the scale of geography.
Put a CDN in front: the FIRST Sydney customer misses (the edge fetches each photo from Virginia once and keeps it), and every Sydney customer after that gets the photos from ~20ms away. The menu loads in under a second, and Virginia serves each photo to Sydney approximately once.
Sydney → Virginia round trip
~200 ms
Sydney → local edge
~20 ms
Menu load
6 s → <1 s
Quick check
Which of these should be served from a CDN edge?
One photo, traced through the edge
Follow margherita.jpg for Sydney. Customer one requests it; their phone is routed to the Sydney edge automatically (the CDN answers the domain lookup with whichever edge is closest). The edge checks its disk: not there — a miss. It fetches the photo from the Virginia origin (one 200ms trip), stores a copy, and returns it.
Customer two, five seconds later, hits the same Sydney edge: found — a hit. 20ms, and Virginia never hears about it. Repeat for the next hundred thousand Sydney customers. Tokyo, London and São Paulo each do their own single miss and then serve locally too.
It is the exact rhythm from the caching lesson — miss → fetch → remember → hits until expiry — with one twist: there are hundreds of these caches, one per city, all filling independently from your single origin.
Edge or origin — where each thing is served from
Split by one question: same for everyone, or personal and live?
| Content | Same for everyone? | Served from |
|---|---|---|
| Pizza photos, logos, fonts | Yes | CDN edge |
| The app bundle (JS/CSS) | Yes | CDN edge |
| Menu DATA (prices) | Yes, briefly | Edge with a short TTL — or app cache |
| Cart contents, order status | No — per user, live | App servers |
| Checkout / payment calls | No — must run your logic | App servers |
Common trap — The classic trap: updating a cached file
You replace margherita.jpg with a better photo — and Sydney keeps showing the old one for hours, because hundreds of edges each hold their own copy until TTL expiry. Chasing every edge to delete it ('invalidation') is slow and error-prone. The professional dodge: NEVER reuse a filename. Upload the new photo as margherita-v2.jpg and update the menu to point at it — a brand-new name misses everywhere instantly, and the old file dies quietly when its TTL runs out.
Quick check
You must replace the site logo TODAY and it is cached on 200 edges with a 7-day TTL. What actually works?
Match them up
Match each term to its plain meaning.
0/5 matched — tap a term on the left.
Build it yourself
Fix the 6-second Sydney menu. Photos should be answered by the CDN and only fetched from origin storage on a miss; API calls (cart, orders) still go to the app servers. One palette piece belongs to a WRITE-shaped pain — leave it off.
Apply it in an interview
Redirects that "must feel instant" for users everywhere — where does an edge cache fit in a URL shortener? Take it into the interview and argue the case.