Your servers may sit in one place, but your users are spread all over the world. Static files — images, CSS, JavaScript, video — almost never change. Making every user reach a far-away server to get them is slow and wasteful. A CDN fixes this by moving copies of those files close to each user.
The animation on the right compares two paths. First it shows a user fetching a file from a far-away origin (the slow way). Then it shows the CDN path: the first request to a nearby edge server is a "miss" (the edge has to fetch the file from the origin once), and every request after that is a fast local "hit".
What a CDN is
CDN (Content Delivery Network)
A worldwide network of edge servers that keep copies of your static files near your users. The user gets the file from the closest edge server instead of from the far-away origin.
Origin server
The one true source of the content — where the real files live. The CDN copies from it the first time a file is needed (a cache miss), then serves everyone else from the local copy.
CDNs put edge servers — called Points of Presence (PoPs) — in big cities around the world. A user in Tokyo reaches a Tokyo PoP. A user in London reaches a London PoP. The origin can live anywhere, and both users still get a fast response.
Well-known CDN providers: Cloudflare, AWS CloudFront, Fastly, Akamai, Google Cloud CDN.
Why it helps
- Faster (lower latency). A trip to a nearby city takes a few milliseconds instead of 150+ ms across an ocean.
- Less work for the origin. The origin is hit once per region per file, not once per user.
- Cheaper bandwidth. Sending data out of a CDN costs less than sending it out of your cloud origin.
- Protection from attacks. CDN providers soak up large traffic-flood (DDoS) attacks at the edge before they ever reach your origin.
- Stays up under pressure. The edge keeps serving its cached files even if the origin has a bad moment.
This is the same caching idea from Chapter 4, just applied to geography: the first request in a region is a miss (the edge fetches from the origin and saves a copy), and every request after that is a hit.
Pull CDN vs. Push CDN
There are two ways files get onto the edge servers.
Pull CDN
The edge fetches a file from the origin only when someone first asks for it (the first cache miss). You do not have to do anything special — just point the CDN at your origin URL. Good for: most web files and APIs that send caching headers.
Push CDN
You upload the files to the CDN ahead of time. The CDN stores them and serves them without ever asking the origin. Good for: large static files, software downloads, and on-demand video.
Most web apps use a pull CDN — there is nothing to set up, and the edge fills itself as traffic comes in. A push CDN is better when files are large, rarely change, and you want them available even if your origin goes down.
Cache-control headers
The CDN reads simple HTTP headers from your origin to decide how long to keep a file:
Cache-Control: public, max-age=31536000, immutable
| Header | What it tells the cache |
|---|---|
max-age=N | Keep the file for N seconds |
s-maxage=N | Like max-age, but only for shared caches like a CDN |
no-cache | Check with the origin before serving |
no-store | Never cache this (use for private data) |
immutable | This file will never change — no need to check again |
stale-while-revalidate=N | Serve the old copy now while quietly fetching a fresh one |
Updating files at the CDN layer
Be clear about what belongs on a CDN: static files that are safe to cache — not personalized,
per-user API responses. When asked how you avoid serving an old file, mention versioned URLs
(/app.9f2c.js) so a new deploy gets a brand-new URL and an old copy can never sneak through.
Versioned URLs (filenames that include a content hash) are the best approach. When a file changes, its name changes too:
/app.abc123.jsbecomes/app.def456.js- The old URL stays cached and valid (people who already loaded the old page still get the matching old file)
- The new URL starts fresh with no cache (and warms up on its own as people request it)
Manual purge (a cache-clearing API) lets you wipe specific URLs or path patterns right away. Use it for files that do not have versioned names, like blog posts or HTML pages. A purge spreads across the whole world in seconds.
CDN for dynamic content
CDNs are not only for static files. Edge computing lets you run small bits of logic right at the PoP, close to the user:
Edge functions (Workers)
Tiny JavaScript or WebAssembly functions that run at the CDN edge, near the user. Used for: login checks, A/B testing, redirects based on location, rewriting requests, and rate limiting — all without a trip back to the origin.
Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute@Edge are examples. The trade-off is a limited runtime (no file system, limited CPU) and a small startup delay (a "cold start") on the first request.
Sending users to the nearest edge
CDNs use anycast routing: many PoPs share the same IP address, and the internet's routing system (BGP) automatically sends each user's traffic to the closest PoP. Your DNS entry points to the CDN's shared address, so the routing is invisible to you.
Some CDNs also offer geo-specific CNAME: they give different DNS answers in different regions, sending users to their regional cluster. This gives you more control, but your DNS provider has to support geo-DNS (like Route53 or Cloudflare).
Video streaming and CDN
Streaming video pushes the CDN idea to its limit:
- A 4K movie is about 50 GB. Streaming it straight from one origin to millions of viewers at once is impossible.
- Adaptive Bitrate Streaming (ABR): the video is saved at several quality levels (360p, 720p, 1080p, 4K). The player asks for small pieces (about 2–10 seconds each) at the quality that fits the current network speed.
- Each piece is just a static file — perfect for the CDN to cache. The player downloads the pieces in order and keeps a few seconds buffered ahead.
- Netflix, YouTube, and Twitch all deliver video this way, using thousands of edge PoPs.
Faster dynamic content too: even API responses that cannot be cached can be quicker over a CDN. Routing the request through the CDN's fast private backbone — instead of the open public internet — speeds up the connection setup (the TCP/TLS handshake) to your origin. AWS CloudFront and Cloudflare Spectrum offer this.
CDN cost is real (and large)
A CDN shows up in every video-design answer, and it is also the first thing to optimize, for one reason: you pay for every GB the CDN sends out to viewers, and at video scale that bill is huge.
Work the rough math out loud — it shows you understand the money side, not just the boxes. At about $0.02/GB on Amazon CloudFront, a fairly small video product looks like this:
5M DAU × 5 videos/day × 0.3 GB/video × $0.02/GB ≈ $150,000 / day
That is about $55M/year in CDN traffic alone, for a service smaller than YouTube. Cloud providers give big discounts to large customers, but the cost stays large — and it grows the more people watch.
Long-tail distribution
Video views are very lopsided: a small number of videos get most of the views, while a huge pile of videos get few or no views. This imbalance is the lever every cost trick pulls on.
Cost-saving levers
| Lever | Why it works |
|---|---|
| Serve only popular videos from the CDN | The long tail of rarely-watched videos almost never gets requested — serve those from your own storage servers and pay CDN fees only for the popular head. |
| Encode unpopular videos only when asked | Do not pre-build and store every quality level for cold videos. A short, rarely-watched video can be converted the first time someone actually plays it. |
| Do not copy region-only content everywhere | A video popular in just one region does not need to sit in PoPs worldwide. Place it where the demand actually is. |
| Build your own CDN + partner with ISPs | At huge scale, run your own edge boxes inside ISP networks (Comcast, AT&T, Verizon). This is how Netflix Open Connect works — the boxes physically sit in ISP data centers, close to users, cutting both delay and bandwidth fees. |
That last lever is a giant project that only makes sense for the very largest streaming companies — but naming Open Connect shows you know where the ceiling is.
How much traffic the CDN absorbs
The cost section asked "how big is the bill?" The other half of the math is "how much traffic does the CDN soak up?" — because that tells you how small (and cheap) your origin can be. Work out the total traffic first, then apply the edge hit ratio (the share of requests served from cache) to see what is left for the origin.
Take an image-heavy site serving 10M file requests/day, with an average file size of 500 KB:
Total traffic out = 10M req/day × 500 KB
= 5 × 10^9 KB/day
≈ 5 TB/day (leaves the edge, goes to users)
That 5 TB is what users pull. The number that sizes your origin is: how much of that does the origin have to serve? With a healthy 95% hit ratio, only the 5% of misses reach back to the origin:
Origin traffic = 5 TB/day × (1 − 0.95)
= 5 TB × 0.05
≈ 250 GB/day (origin → edge, on misses only)
Offload factor = 5 TB / 250 GB = 20×
So the origin serves about 250 GB/day instead of 5 TB/day — a 20× drop. That ratio is the whole point of a CDN, stated as a number: the origin (and its pricey cloud bandwidth) shrinks by 20×, while the cheap edge carries the rest. Push the hit ratio from 95% to 99% and the origin load drops to about 50 GB/day — a 100× offload — which is exactly why good cache keys and long TTLs (the headers above) pay off.
| Edge hit ratio | Origin traffic/day | Offload factor |
|---|---|---|
| 90% | ~500 GB | 10× |
| 95% | ~250 GB | 20× |
| 99% | ~50 GB | 100× |
Peaks matter as much as the daily total. 5 TB/day averages out to about 460 Mbps, but a launch or a viral moment can spike 10×. The edge soaks up that burst, so your origin's bandwidth (and its autoscaling) only needs to handle the trickle of misses, not the whole crowd.
The senior move is to name the hit ratio as the lever, not just say "the CDN offloads the origin." Say: "At a 95% hit ratio, 5 TB/day of traffic leaves the origin serving only about 250 GB/day — a 20× reduction — and every point I push that ratio up shrinks origin bandwidth and cost even faster." Tying the number to why (cache keys, TTLs, versioned URLs all raise the ratio) is what turns a memorized figure into real understanding.
When asked to design YouTube or Netflix, bring up the CDN cost estimate before the interviewer asks: "At about $0.02/GB, 5M DAU streaming 5 videos a day is roughly $150K/day in traffic — so I would serve only the popular head from the CDN, keep the long tail on cheaper origin storage, encode cold videos on demand, and only copy region-popular content to that region." That one answer covers both the money and the four levers.
The video transcoding pipeline
Those CDN-cached video pieces do not appear by magic — they are the output of a transcoding pipeline that runs the moment a creator uploads a file. Raw video cannot be delivered as-is: an hour of HD at 60fps can be hundreds of GB, and devices only accept certain formats. Transcoding (also called encoding) turns the raw upload into compatible, compressed streams at several quality levels.
Container vs. codec
A container (.mp4, .mov, .avi) is the basket that holds the video stream, audio stream, and
metadata together — you can tell it from the file extension. A codec (H.264, VP9, HEVC) is
the algorithm inside that compresses the data while keeping the quality. Container = packaging;
codec = compression.
GOP chunking: split before you process
GOP (Group of Pictures)
A chunk of video frames that can play on its own, usually a few seconds long. Video is split along GOP boundaries before transcoding.
Splitting the upload into GOP chunks gives you two wins:
- Resumable uploads. If the network drops, you start again from the last finished chunk instead of re-sending a whole 1 GB file. The client can even do the splitting itself to speed things up.
- Parallel transcoding. Independent chunks can be transcoded on different machines at the same time, so a long video does not wait in line behind one worker.
Some old phones and browsers cannot split by GOP. The fallback: the client uploads the whole file and the server does the splitting. Always have a server-side path for clients that cannot do the work themselves.
The DAG model: parallel transcoding stages
Different creators need different processing — watermarks, their own thumbnails, different resolutions. One hard-coded pipeline does not scale. Instead, model the work as a Directed Acyclic Graph (DAG) — a chart of tasks where arrows show which task depends on which (the approach Facebook's streaming video engine uses). Independent tasks run at the same time, and dependent ones run in order.
A typical DAG splits the original into video / audio / metadata, then branches out:
| Task | What it does |
|---|---|
| Inspection | Check the quality; reject broken or corrupt uploads early. |
| Video encoding | Make several resolutions / codecs / bitrates (this is what feeds ABR). |
| Thumbnail | Auto-generate one, or use the creator's own image. |
| Watermark | Stamp identifying info (a logo, a channel name) onto the video. |
A DAG scheduler breaks the chart into stages and hands tasks to a resource manager (a task queue + a worker queue + a running queue) that gives each task to a free worker. When all transcoding is done, a completion queue and completion handler quietly update the metadata DB/cache and push the finished files to the CDN. A message queue is what keeps the stages separate: the encoding step does not sit blocked waiting on the download step — it just picks up events as they arrive.
Say "I would model transcoding as a DAG of tasks — inspect, encode to multiple bitrates, thumbnail, watermark — so independent stages run in parallel, and split the video into GOP chunks so uploads are resumable and chunks transcode at the same time." It shows you see the pipeline as parallel work, not one black-box "encode" step.
Upload safety and content protection
If you let clients upload straight to your blob storage (cloud file storage like S3), you have a permission problem: how do you grant access to one file without handing out your storage password? And once a video is online, creators want it protected from theft.
Pre-signed upload URLs
Pre-signed URL
A short-lived, single-file URL that grants permission to upload to one exact spot in blob storage — without exposing your storage credentials. The client asks your API server for one, the server signs it, and the client uploads straight to blob storage with that URL. AWS S3 calls it a pre-signed URL; Azure Blob Storage calls the same thing a Shared Access Signature (SAS).
The flow has three steps: (1) the client asks the API server for a pre-signed URL, (2) the API server returns a signed URL scoped to one file, (3) the client uploads the file straight to storage. This keeps large uploads off your API servers entirely, while making sure only authorized users can write, and only to the right spot.
Protecting the content itself
| Protection | What it does |
|---|---|
| DRM systems | Lock playback behind a license. The three big ones: Apple FairPlay, Google Widevine, Microsoft PlayReady. |
| AES encryption | Encrypt the video, set an access policy, and decrypt only at playback for authorized users. |
| Visual watermarking | Stamp an image (a logo or company name) onto the video — it deters theft and helps trace leaks. |
Bring up pre-signed URLs without being asked for any upload feature: "The client uploads straight to blob storage with a pre-signed URL (S3 pre-signed / Azure SAS), so credentials never leave the server and the upload skips the API servers." It is the standard, secure direct-to-storage pattern and shows you have shipped real upload flows.
CDN fallback: surviving an edge outage
A CDN is something you depend on, and things you depend on can fail — a whole PoP, or even a whole provider, can have a bad day. Since the CDN sits right in the user's read path, an outage there is a user-facing outage unless you plan for it.
The pattern: the client notices the CDN failed and falls back to the origin. If a request to the CDN times out or returns a 5xx error, the player retries against the origin URL (or a backup CDN). You trade higher latency and more origin load for staying up — degraded is better than down.
Do not let the origin get crushed when it suddenly becomes the fallback for everyone. Pair CDN fallback with rate limiting on the origin, and make sure the origin can at least serve the popular head of the catalog — otherwise a small CDN blip turns into a full origin meltdown.
"I would make the client CDN-aware: on a timeout or 5xx from the edge, fall back to the origin or a backup CDN. The CDN is in the critical read path, so one provider's outage should not take the product down — multi-CDN or origin fallback turns it into graceful degradation." Treating the CDN as a dependency that can fail, not infrastructure that is always there, reads as senior.
Practice
Answer these to check you understood how a CDN works.
1. What is the main job of a CDN?
2. On the very first request for a file in a region, what happens?
3. Why are versioned URLs (like /app.def456.js) a good way to update files?
4. At a 95% edge hit ratio, roughly how much does the origin's traffic shrink compared to serving everything itself?
5. Why split a video into GOP chunks before transcoding?