Skip to main content

CDN

A CDN (Content Delivery Network) is caching applied to geography: a network of servers, called edge servers or points of presence (PoPs), physically distributed around the world, each holding a cached copy of content close to the users who request it. Every other cache in this module has been about skipping work (a database query, a computation); a CDN is specifically about skipping distance — the physical time it takes a signal to travel.

Why distance is a hard floor on latency​

No amount of server optimization changes the fact that data takes time to travel — even at the speed of light, a round trip between New York and Sydney takes over 100ms just from the physical distance, before either server does a single millisecond of actual work. This is exactly the fixed cost Latency vs. Throughput vs. Bandwidth describes as a physical constant, not an engineering problem to optimize away. A CDN's entire value proposition is sidestepping that floor: instead of every request traveling to one origin server, it travels to whichever edge location is geographically nearest, and only that edge server occasionally talks to the origin.

System Design Lab

Getting a user to the nearest edge​

A CDN needs a mechanism to route each user's request to their geographically closest edge server in the first place, and this connects directly back to two earlier lessons: geo-DNS resolves a domain name to a different IP address depending on where the query originated, effectively pointing each user at the nearest edge location before a single byte of the actual request is sent — the DNS-based load-balancing case briefly mentioned in DNS and Load Balancing. This is DNS and load balancing operating at planetary scale rather than within one datacenter.

Static vs. dynamic content​

CDNs were built for, and are most effective on, static content — images, video, CSS, JavaScript bundles, anything that's identical for every user and changes infrequently. That content can be cached at the edge for a long time with a simple TTL, and served entirely 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 another, so CDNs either don't cache it at all (proxying straight through to the origin) or use narrower techniques like edge computing (running small pieces of application logic at the edge itself) to personalize responses without a full round trip to the origin.

CDNs and origin protection​

A secondary effect worth naming explicitly: because most requests for cacheable content are absorbed at the edge, the origin server only ever sees cache misses and genuinely dynamic requests — a large fraction of total traffic never reaches it at all. This is the same load-shedding effect any cache has on the layer behind it (see Caching 101), just at the scale of an entire global user base instead of one application server's database. It's also a meaningful defense against traffic spikes and some categories of denial-of-service traffic, since the attack surface facing the public internet is the CDN's much larger edge fleet, not the origin itself.

Push vs. pull CDNs​

CDNs populate their edge caches one of two ways: pull — the edge server fetches and caches content from the origin lazily, the first time it's requested (the standard cache-aside pattern from Caching Strategies, applied at the edge) — or push — content is proactively uploaded to every edge location ahead of time, before any user requests it. Pull is simpler and is the default for most web content; push is used when content needs to be guaranteed present at the edge before the first request (a scheduled video release, for instance). This maps directly onto the general Push vs. Pull Architecture tradeoff.

Why this matters in an interview​

Any design serving a geographically distributed user base — especially one with meaningful static assets (images, video, a JS bundle) — should name a CDN explicitly rather than leaving "the client fetches this over the internet" implicit. It's also worth being ready to draw the static/dynamic line: naming which parts of a design a CDN actually helps with, and which parts (personalized, per-user data) still have to hit the origin, is what separates a real answer from name-dropping "CDN" as a buzzword.

Serving static content from a CDN: pros and cons​

Pros

  • Cuts latency by serving from a location physically close to the user
  • Absorbs the vast majority of traffic for cacheable content, protecting the origin
  • Improves resilience to traffic spikes and some denial-of-service traffic

Cons

  • Not a good fit for highly personalized or frequently-changing dynamic content
  • Adds another layer with its own caching/invalidation behavior to reason about
  • Purging or updating content across every edge location isn't instantaneous

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.