Content Delivery Networks (CDNs)

A CDN (Content Delivery Network) is a geographically distributed network of servers that delivers content from the location closest to the user. Think of it like having copies of a book in libraries across the country instead of one central warehouse — people get the book faster because they go to the nearest library.

How a CDN Works

Here’s the flow:

1. User in India requests image.png from our site
2. DNS routes the request to the nearest CDN edge server (Mumbai)
3. If the edge has it cached → return immediately (cache hit)
4. If not → edge fetches from origin server, caches it, returns to user (cache miss)
5. Next user in India requesting the same file gets it from Mumbai instantly

The first request is slow (has to go to origin). Every subsequent request from that region is fast.

Push CDN vs Pull CDN

Pull CDN — The CDN fetches content from our origin server on demand (when someone requests it). Content is cached after the first request and expires based on TTL.

• We don’t manage what’s on the CDN
• Works great for high-traffic sites (content gets cached quickly)
• Simpler to set up

Push CDN — We explicitly upload content to the CDN. We decide what’s cached and when it’s updated.

• Full control over what’s on the CDN
• Better for content that changes infrequently (firmware files, large media)
• More work to manage

Most websites use Pull CDN. It’s simpler and handles most use cases well.

What to Put on a CDN

Great for CDN:

• Images, videos, audio files
• CSS, JavaScript bundles
• Fonts
• Static HTML pages
• Large downloadable files (PDFs, installers)

Not great for CDN:

• Dynamic API responses (changes per user/request)
• Private/personalized content
• Real-time data (stock prices, live scores)
• Very rarely accessed content (wastes edge storage)

CDN Invalidation

When we update content on our origin server, the CDN still has the old version cached. We need to invalidate it:

1. TTL expiration — Set a Time To Live. After it expires, the edge fetches fresh content. Simple but has a delay.
2. Explicit invalidation — Tell the CDN to purge specific files. Instant but costs money per request on some providers.
3. Versioned URLs — Use style.v2.css instead of style.css. The new URL is a cache miss, so fresh content is fetched. This is the most reliable approach.

Popular CDNs

CDN in System Design

In interviews, mention CDN whenever the system serves static content to a global audience. It’s a quick win that dramatically reduces latency and server load.

A typical architecture mention:

User → CDN (static assets) → Load Balancer → App Server → DB
         ↑
   Serves images, JS, CSS
   without hitting our servers

The performance impact is massive. Instead of a user in Tokyo making a round trip to our US server (150ms+), they hit a Tokyo edge server (5ms). For media-heavy sites like Instagram or Netflix, CDNs handle the vast majority of traffic — our origin servers barely break a sweat.

In simple language, a CDN puts copies of our content closer to users around the world. Less distance = less latency = happier users. For any system that serves files or media globally, a CDN is a no-brainer.