System Design

What Is a Content Delivery Network (CDN)?

The reason a video loads instantly whether you're in Tokyo or Toronto is a CDN - a global network of servers caching content close to users. Here's what a CDN is, how it works, and why nearly every large system uses one.

By Admin2026-06-1814 min readcdnnetworkingcachingperformancesystem-designinfrastructure

When you stream a video, load a website's images, or download a file, it often feels instant - whether you're in Tokyo, Toronto, or Lagos. That's not because the origin server is impossibly fast; it's because the content was served from somewhere physically close to you, by a Content Delivery Network (CDN). CDNs are one of the most important pieces of infrastructure on the modern internet, and "add a CDN" is one of the most common moves in system design. This guide explains what a CDN is, how it works, and why nearly every large system uses one.

The problem a CDN solves

Start with the problem. Suppose your servers (your origin) are in one location - say, a data center in the US. A user in the US gets fast responses. But a user in Australia is physically far away, and data takes time to travel that distance - the speed of light is a real limit. Their requests cross oceans, adding latency (delay) to every load. Far-away users get a slow experience, no matter how fast your servers are, simply because of distance.

There's a second problem: if every user worldwide hits your single origin, that origin bears all the load - every image, video, and file request - which is a lot of traffic to serve and a lot of load to handle.

A CDN solves both. By caching your content on servers distributed around the world, it serves users from a nearby location (cutting latency) and absorbs most of the traffic (offloading the origin). Distance shrinks, and the origin breathes.

What a CDN is

A CDN is a geographically distributed network of servers that cache and deliver content from locations close to users. These servers - called edge servers or points of presence (PoPs) - are placed in many locations around the world. Each holds cached copies of your content, so a user's request can be served from the edge server nearest them rather than traveling all the way to your origin.

Think of it as having copies of your content in warehouses all over the world, so deliveries come from the warehouse closest to each customer instead of shipping everything from one central location. The CDN is that distributed warehouse network for your content.

graph TD
    O[(Origin server<br/>your data center)] --> E1[Edge server<br/>North America]
    O --> E2[Edge server<br/>Europe]
    O --> E3[Edge server<br/>Asia]
    U1[User in US] --> E1
    U2[User in Germany] --> E2
    U3[User in Japan] --> E3

This diagram shows a CDN. A single origin server in your data center distributes content to edge servers placed around the world - in North America, Europe, and Asia. Users are served from the edge server nearest them: a user in the US is served from the North American edge, a user in Germany from the European edge, a user in Japan from the Asian edge. Serving content from nearby reduces latency and offloads the origin.

How a CDN works

Here's the flow when a user requests content through a CDN:

1. The user requests some content (an image, a video, a file). Through DNS-based routing, the request goes to the nearest edge server, not the distant origin.
2. The edge server checks whether it has the content cached. Cache hit: it has a fresh copy, so it serves it immediately - fast, and the origin is never touched.
3. Cache miss: the edge server doesn't have it (or its copy expired), so it fetches the content from the origin, serves it to the user, and caches it for next time. The first request for content at a given edge is a miss; subsequent ones are fast hits.

So a CDN works by caching content at the edge and serving from there. The first user in a region might trigger a fetch from origin, but everyone after them is served the cached copy from nearby. Over time, popular content lives cached across the edge network, and the vast majority of requests are fast hits served close to users, with only misses reaching the origin.

How users get routed to the nearest edge is itself clever - typically through DNS-based routing or anycast (where the same address is announced from many locations and the network delivers each user to the closest one). The result is that users automatically reach the edge server best positioned to serve them.

What CDNs deliver

CDNs were originally for static content - files that don't change per user: images, videos, CSS, JavaScript, downloads, fonts. Static content is ideal for caching because it's the same for everyone, so an edge server can cache one copy and serve it to many users. This remains the core CDN use case, and it's a large fraction of what most sites serve.

Increasingly, CDNs do more: they cache some dynamic content, accelerate API responses, terminate TLS at the edge (handling the secure connection closer to the user), and provide security features (absorbing attacks, filtering malicious traffic) since they sit between users and the origin. Modern CDNs have grown from "cache static files" into broad edge platforms - but the foundational job, and the one to understand first, is caching content close to users.

Cache control and invalidation

A practical challenge: if content is cached at edges worldwide, how do you update it? If you change an image but edges still serve the old cached copy, users see stale content. CDNs handle this with:

• TTLs (time-to-live). Each cached item has a TTL saying how long it may be served before the edge re-checks with the origin. Short TTLs keep content fresh but increase origin fetches; long TTLs maximize cache benefit but risk staleness.
• Cache invalidation / purging. You can explicitly tell the CDN to purge content, forcing edges to fetch fresh copies - used when you push an important update that can't wait for TTLs to expire.
• Versioned URLs. A common trick: include a version in the file's URL (like style.v2.css), so an update is a new URL the CDN hasn't cached, sidestepping staleness entirely.

Managing this freshness-versus-performance trade-off is part of using a CDN well - you want maximum caching benefit without serving stale content.

Push vs. pull CDNs

There are two models for how content gets onto a CDN's edge servers:

• Pull CDN. The CDN fetches content from your origin on demand - the first time an edge needs a piece of content (a cache miss), it pulls it from the origin and caches it. You don't proactively upload anything; the CDN populates itself based on what users request. This is the most common model: simple to set up (point the CDN at your origin and go), and the cache naturally fills with the content people actually want. The downside is that the first request to each edge is a slower miss.
• Push CDN. You proactively upload content to the CDN ahead of time, so it's already at the edges before anyone requests it. This gives control over exactly what's cached and avoids the first-request miss, but requires you to manage uploading and updating. It suits cases where you know in advance what needs distributing (a big release, large files you want pre-positioned).

Most general web content uses pull (simpler, self-managing); push suits specific scenarios with large or predictable content. Knowing both shows you understand that getting content to the edge isn't one-size-fits-all.

What makes content cacheable

Not all content benefits from a CDN equally. The ideal CDN content is:

• Static - the same for every user (an image, video, CSS or JavaScript file, downloadable file). Because it's identical for everyone, one cached copy at an edge serves all users in that region.
• Frequently requested - popular content benefits most, because the cost of the initial origin fetch is amortized across many cache hits.
• Relatively stable - content that doesn't change every second, so a cached copy stays valid long enough to be reused.

Content that's personalized (different for each user) or constantly changing caches poorly - there's little reuse, so the cache rarely helps. This is why static assets are the classic CDN content and why dynamic, per-user content traditionally bypassed the CDN. The practical skill is recognizing which parts of your system are cacheable (the static assets, the public content) and routing those through the CDN, while dynamic per-user requests go to the origin.

The mechanism that controls all this is cache-control headers - instructions your origin sends with content telling the CDN (and browsers) how to cache it: whether it's cacheable, for how long, and whether it's public or private. Setting these correctly is how you tell the CDN exactly how to treat each piece of content.

A worked example: a video platform

To see a CDN in action, consider how a video platform serves content globally. The videos - large, static, watched by many people - are perfect CDN content. When a video is uploaded, it lives in origin storage. The first time someone in a region watches it, the nearby edge fetches it from origin (a miss) and caches it. Every subsequent viewer in that region is served the cached copy from the nearby edge - fast, without touching the origin.

For a popular video, this means the origin serves it just once per region, and the CDN's edges serve it to millions of viewers worldwide from nearby. Without a CDN, every view would stream from the origin across potentially vast distances - slow for distant users and an impossible load on the origin. With a CDN, the load is distributed across the edge network and every viewer gets low-latency delivery from close by. This is exactly why video platforms, image-heavy sites, and any global content service rely on CDNs - it's the only practical way to deliver heavy content to a worldwide audience quickly.

Modern CDNs: more than caching

CDNs have evolved beyond their original "cache static files" role into broad edge platforms:

• TLS termination at the edge. The CDN can handle the secure (HTTPS) connection at the edge near the user, rather than every connection going all the way to the origin to be secured. This speeds up the secure handshake (it happens closer to the user) and offloads work from the origin.
• Edge compute. Modern CDNs let you run code at the edge - small programs executing on the edge servers near users, for customizing responses, handling authentication, or generating dynamic content close to the user instead of at a distant origin. This pushes not just content but computation closer to users.
• Security services. Sitting between users and origin, CDNs absorb and filter large traffic floods (so attacks hit the distributed edge rather than the origin), block malicious requests, and act as a protective shield in front of the origin.
• Dynamic acceleration. Even for content that can't be fully cached, CDNs can accelerate delivery through optimized network routing between edge and origin, faster than the public internet path.

The throughline is that the CDN's position - distributed, close to users, between them and the origin - makes it useful for far more than caching. But the foundational job remains the one to understand first: caching content close to users to cut latency and offload the origin.

When a CDN helps most (and when it doesn't)

A CDN is near-universal for large systems, but it's worth knowing where it shines and where it adds little. A CDN helps most when you have static or cacheable content (images, video, scripts, files), a geographically distributed audience (users far from your origin), high traffic (so caching offloads meaningful load), and repeatedly-requested content (so the cache gets reused). The more of these are true, the bigger the win.

A CDN helps less when content is highly personalized or constantly changing (little to cache and reuse), when your audience is concentrated near your origin (less distance to overcome), or when traffic is low (the caching benefit is small relative to the added moving part). In those cases a CDN isn't wrong, but its value is modest - and like any infrastructure, it adds a layer to configure and reason about. The judgment is matching the tool to the situation: for global, static-heavy, high-traffic content, a CDN is close to essential; for a small, dynamic, regionally-concentrated app, it may be premature. As with most system design choices, you add it when the situation genuinely calls for it, not reflexively - though for the large-scale, media-heavy systems that dominate system design discussions, it almost always does.

Why CDNs matter

Pulling it together, CDNs deliver several benefits that make them near-universal for large systems:

• Lower latency. Content served from nearby is faster - the single biggest reason to use a CDN. Distance, and the delay it causes, is reduced.
• Reduced origin load. Edges absorb most requests, so the origin handles far less traffic - improving scalability and reducing cost.
• Higher availability. With content distributed across many edges, the system is more resilient; an origin problem or traffic spike is buffered by the edge network.
• Better global reach. Users everywhere get a good experience, not just those near the origin.
• Security. Sitting between users and origin, CDNs can absorb and filter attacks, protecting the origin.

Interview: "Add a CDN" is one of the most common and expected moves in system design, especially for anything serving static content, media, or a global audience. The strong answer explains why: it serves content from edge servers near users (cutting latency), offloads the origin (improving scalability), and improves availability. Mentioning the cache hit/miss flow, that it's ideal for static content (images, video, JS/CSS), and the invalidation challenge (TTLs, purging, versioned URLs) shows real depth. For any system with users spread across regions or heavy static/media content, proposing a CDN signals you understand global-scale delivery.

The bottom line

A CDN is a geographically distributed network of edge servers that cache content close to users. It solves two problems at once: distance-induced latency (by serving from a nearby edge instead of a distant origin) and origin overload (by absorbing most requests at the edge). When a user requests content, they're routed to the nearest edge, which serves it from cache (a fast hit) or fetches it from the origin once and caches it (a miss). CDNs excel at static content - images, video, scripts - and increasingly handle dynamic content, TLS termination, and security too, with freshness managed through TTLs, purging, and versioned URLs.

The payoff is lower latency, reduced origin load, higher availability, and better global reach - which is why nearly every large system uses one. We cover CDNs and content delivery across System Design Fundamentals.

Go deeper

• Content delivery network (Wikipedia) - the full picture of how CDNs work.
• Cloudflare - What is a CDN? - a clear, practical explanation.
• AWS - What is a CDN? - CDNs from a cloud infrastructure perspective.
• The System Design Primer - CDNs among the system design building blocks.

More articles