System Design CDN: Serving Content Fast Globally

Table of contents

Introduction

CDN is the reason apps feel fast everywhere in the world, not just near your servers. It’s the same caching principle from Redis — but applied geographically.

The Problem

Your servers are in Mumbai. A user in New York requests a video.

New York → request travels across globe → Mumbai server
Mumbai → video travels back across globe → New York

Round trip: 200-400ms (just network latency)

Multiply by 50 million concurrent viewers during an IPL match — your Mumbai server has a physical impossibility problem. Light itself only travels so fast.

What a CDN Is

A globally distributed network of servers that cache your content close to your users.

Without CDN:
50M users → Mumbai server (dies)

With CDN:
Users in New York → CDN node in New York
Users in London → CDN node in London
Users in Tokyo → CDN node in Tokyo
Users in Mumbai → CDN node in Mumbai

Mumbai origin server only talks to CDN nodes — not users directly

CDN nodes are called Points of Presence (PoP). Providers like Cloudflare, Akamai, and AWS CloudFront have hundreds of PoPs globally.

How It Works

First request — cache miss:

User in London requests a video
→ Nearest CDN node (London): cache miss
→ London node fetches from Mumbai origin
→ Stores copy locally
→ Serves to user

Every subsequent request — cache hit:

Next user in London requests same video
→ London CDN node: cache hit
→ Served directly from London
→ Mumbai server never involved

Same cache-miss / cache-hit logic as Redis — just at a geographic level.

What Belongs on a CDN

Good fit — static or semi-static:

• Videos, images, thumbnails
• CSS, JavaScript, fonts
• HTML pages (articles, docs, blog posts)
• Software downloads, audio files

Not suitable — dynamic or personalised:

• Personalised API responses (“show MY feed”)
• Real-time data (live scores, stock prices)
• Authenticated, user-specific content
• Any server-side logic computed per request

The rule: CDN only works when content is the same for all users in a region.

TTL on a CDN

Just like Redis, CDN content has a TTL. After expiry, CDN fetches fresh from origin.

Cache Invalidation

What if you need to update content before TTL expires?

Option 1 — Explicit purge:

Journalist edits article
→ CMS sends API call to CDN: "purge /articles/article-slug"
→ All CDN nodes delete their copy
→ Next request fetches fresh from origin

Option 2 — Cache busting (URL versioning):

Old: styles-v1.css → cached everywhere
New: styles-v2.css → new URL = CDN treats as brand new

Or with build hashes:
styles.a3f9b2c1.css → hash changes on every build
→ CDN always fetches latest version

Cache busting is why frontend build tools add hashes to filenames automatically.

Beyond Static Files

CDN for API responses:

API responses that are identical for all users can be cached at CDN level.

GET /api/trending-movies
→ Same for all users
→ Cache at CDN for 5 minutes
→ Millions of requests served from edge
→ Your API server gets near-zero load

Edge Computing:

Run code at the CDN node itself, close to the user.

Old: User in London → request to Mumbai → computed → back → 400ms

Edge: User in London → logic runs at London CDN node → 10ms

This is how Cloudflare Workers and AWS Lambda@Edge work.

Connection to Previous Lessons

CDN is just Redis but geographic:

Lesson 6: User → App → Redis → Database
CDN:      User → CDN → Origin Server

Same pattern, different layer.

CDN reduces load balancer pressure (Lesson 5):

Without CDN:
100% traffic → Load Balancer → App Servers → Database

With CDN:
90% static traffic → CDN nodes (handled)
10% dynamic traffic → Load Balancer → App Servers → Database

Infrastructure cost drops significantly.

CDN + WebSockets for real-time (Lesson 8):

Hotstar IPL — 50M concurrent viewers:

Video stream → CDN nodes (serves the heavy load)
Live scores → WebSocket + Message Queue (real-time, can't cache)
Auth tokens → App servers → Redis sessions
Ad videos → CDN (static), ad targeting → App servers (dynamic)

Each component uses the right tool.

Exercise: News Website

Content: article pages, breaking news banner, personalised “For You” section, embedded images/videos, comment section.

Reference answer:

Breaking news alternative: Redis with 60-second TTL at app level. Same content for all users, just refreshes frequently.

Comment count (not the comments themselves): acceptable to cache in Redis with a short TTL — “1,243 comments” being 30 seconds stale is fine.

Key Takeaways

1. CDN is geographically distributed caching — same logic as Redis, applied to location.
2. Only static or same-for-all-users content belongs on a CDN.
3. TTL and cache invalidation strategy must be planned — not an afterthought.
4. Cache busting (versioned URLs / hashes) solves long TTL + content update conflicts.
5. CDN offloads up to 90% of traffic before it reaches your servers.

Part of the system design series. Phase 2 complete. Next: designing complete real systems from scratch — starting with a URL shortener.