CDN Explained: How Content Delivery Networks Make Sites Fast

🟢 Fundamentals · True fresher level → 🟠 senior nuance

When you watch a video on YouTube or load a photo on Instagram, the data almost never travels from a single server on the other side of the planet. It comes from a machine close to you — maybe in your own city. That's a CDN (Content Delivery Network) at work, and it's one of the highest-impact, easiest-to-explain tools in system design. Let's see exactly what it does and why nearly every large site uses one.

The problem: distance is slow

Data travels near the speed of light, but the planet is big. A request from India to a server in the US and back can take 200–300 milliseconds just in travel time — before the server even does anything. Load a page with 50 images that way and it feels sluggish. Physics won't budge; the only fix is to move the content closer to the user. That's the entire idea.

How a CDN works

A CDN operates many edge servers (also called Points of Presence, or PoPs) in data centres across the world. Your real server is the origin. The CDN caches copies of your content on those edge servers, and each user is routed to the nearest one.

🟠 The key concept is the cache hit vs miss. When a user requests a file:

• Cache hit: the edge already has the file → it serves it immediately. Fast, and the origin isn't touched at all.
• Cache miss: the edge doesn't have it (or it expired) → the edge fetches it once from the origin, sends it to the user, and stores a copy so the next nearby user gets a hit.

So the first request in a region might be a little slower (a miss), but everyone after that is fast. How long the edge keeps a copy is controlled by a TTL (time-to-live) you set — after it expires, the edge re-checks the origin for a fresh version.

The two big wins

• Speed for users: content comes from nearby, so latency drops dramatically — the difference between a snappy site and a sluggish one, especially for a global audience.
• Offloading the origin: if 90% of requests are served by edges, your origin server handles a fraction of the traffic. That's cheaper, and it protects the origin during spikes — the CDN absorbs the flood.

🟠 That second point matters for scale and resilience: a CDN is also a shield. Because edges soak up huge request volumes, CDNs are a first line of defence against traffic surges and even DDoS attacks — the malicious flood hits the distributed edge, not your single origin.

What to put on a CDN (and what not to)

CDNs are perfect for static content — images, videos, CSS, JavaScript, fonts, downloads — files that are the same for everyone and don't change often. That's the bread and butter.

🟠 Dynamic, personalised content (your account page, a live cart) is trickier — it's different per user, so it can't be blindly cached. Modern CDNs still help here via "dynamic acceleration" (optimised network routes to the origin) and edge compute, but the classic, high-value use is caching static assets. A common senior move: serve the HTML dynamically from the origin but load all its images/CSS/JS from the CDN.

The one hard part: cache invalidation

🟠 There's a famous joke that one of the two hardest problems in computing is cache invalidation. If you update a file but edges still serve the old cached copy until its TTL expires, users see stale content. Two standard fixes:

• Purge/invalidate: tell the CDN to drop a file so the next request re-fetches the fresh one.
• Versioned URLs (cache busting): change the filename when the content changes — e.g. style.v2.css or app.9f3a1.js. A new URL is a guaranteed miss, so users always get the latest, and you can cache each version basically forever.

Versioned URLs are the pro approach for assets: long cache lifetimes and instant updates, with no stale-content risk.

The interview-ready summary

"A CDN is a globally distributed set of edge servers that cache my content close to users. Requests hit the nearest edge — a cache hit serves instantly and never touches my origin; a miss fetches once from origin and caches it. This slashes latency for a global audience and offloads most traffic from my origin, which also protects it during spikes. I'd put static assets — images, video, CSS, JS — on the CDN, and handle updates with versioned URLs or purges to avoid stale caches." Clean, complete, and exactly what they want to hear."

What to read next

• Caching Strategies — the caching principles a CDN applies at the edge
• Blob / Object Storage (S3) — where the files a CDN serves usually live
• Latency, Throughput & Availability — why distance-latency matters
• ← The complete System Design guide (hub)

← Microservices architecture · Reverse proxy vs load balancer →