What Is a CDN? A Simple Explanation

Most caching is about skipping work — a database query, a computation. A CDN caches something different: distance itself, the physical time it takes a signal to travel across the planet.

The hard floor no server can optimize away

Even at the speed of light, a round trip between New York and Sydney costs over 100ms from distance alone, before either server does a millisecond of actual work. No amount of backend optimization changes that — it's a physical constant, not an engineering problem. A CDN's entire value proposition is sidestepping it: instead of every request traveling all the way to one origin server, it travels to whichever edge server (or point of presence) is geographically nearest, and only that edge server occasionally talks back to the origin.

System Design Lab

How a user actually reaches the nearest edge

Getting each user routed to their closest edge location is itself a solved problem, built on infrastructure this course already covers: geo-DNS resolves the same domain name to a different IP address depending on where the query originated, pointing a user at the nearest edge before a single byte of the real request is sent. It's the same DNS-based load-balancing idea from ordinary load balancing, just applied at planetary scale instead of within one datacenter.

Static content is the easy case — dynamic content isn't

CDNs were built for, and remain best at, static content: images, video, CSS, JS bundles — anything identical for every user that changes infrequently. That content can sit at the edge behind a simple TTL and get served without ever touching the origin. Dynamic, personalized content — a user's own account page, a live search result — is a much harder fit: caching it at the edge risks serving one user's private data to someone else, so CDNs either skip caching it entirely (proxying straight through) or use narrower techniques like edge computing to personalize responses without a full round trip home.

A side effect worth naming: origin protection

Because most cacheable requests get absorbed at the edge, the origin server only ever sees cache misses and genuinely dynamic traffic — often a small fraction of the total. It's the same load-shedding effect any cache has on the system behind it, just operating at the scale of an entire global user base. It also happens to be a meaningful defense against traffic spikes and some categories of denial-of-service traffic, since the public-facing surface is the CDN's much larger edge fleet, not the origin itself.

Push vs. pull

CDNs populate edge caches one of two ways: pull, where an edge server lazily fetches and caches content the first time it's requested (the standard cache-aside pattern, applied at the edge), or push, where content is proactively uploaded to every edge location ahead of time. Pull is the simpler default; push is used when content has to be guaranteed present before the first request — a scheduled video release, for instance.

Why this matters in an interview

Any design serving a geographically distributed audience — especially one with real static assets — should name a CDN explicitly rather than leaving "the client fetches this over the internet" implicit. Just as important: being ready to draw the static/dynamic line, naming which parts of a design a CDN genuinely helps and which parts still have to hit the origin, is what separates a real answer from name-dropping "CDN" as a buzzword.

Go deeper

The full lesson covers push vs. pull CDNs in more depth and connects back to the general push/pull architecture tradeoff:

👉 Read the full CDN lesson — part of the free System Design Lab course.