System Design
CDN (Content Delivery Network)
When Diablo III launched in 2012, the surge of direct traffic to Blizzard's origin servers caused an 8-hour outage. Netflix avoided this fate by placing Open Connect servers inside ISP data centers - today, over 95% of Netflix traffic never leaves the ISP's network. The difference between having a CDN and not having one is the difference between global streaming and a global outage.
- Netflix Open Connect: 95% of traffic served from ISP-embedded appliances, never hitting origin
- Cloudflare handles ~20% of global HTTP traffic across 300+ PoPs in 100+ countries
- GitHub uses Fastly CDN - static assets served from edge, reducing origin load by 80%+
- Steam game downloads distributed via Akamai CDN - launch-day spikes handled without origin overload
Цели урока
- Understand why CDN is critical for global applications
- Know the CDN architecture: PoP, Edge, Origin, Anycast
- Distinguish between Pull and Push CDN
- Be able to configure Cache-Control headers
- Know invalidation strategies: content hash, purge, versioned URLs
Предварительные знания
- Understanding of HTTP and caching
- Basic understanding of DNS
Why CDNs Are Essential
**CDN (Content Delivery Network)** - a geographically distributed network of servers that delivers content to users from the nearest location. The main goal: reduce latency.
Light travels through fiber at 200,000 km/s. Moscow → New York = 100ms round-trip. This is a physical limit that CDN works around.
- Netflix uses Open Connect - their own CDN with servers at ISPs
- Cloudflare handles ~20% of global internet traffic
- Without a CDN, a site from the USA loads in Moscow in 2-3 seconds
| Route | Round-trip time | With CDN |
|---|---|---|
| Moscow → Moscow | ~1 ms | ~1 ms |
| Moscow → Amsterdam | ~30 ms | ~5 ms (edge) |
| Moscow → New York | ~100 ms | ~5 ms (edge) |
| Moscow → Sydney | ~300 ms | ~5 ms (edge) |
Loading a page with 50 resources
How CDN speeds up loading
Without CDN (origin in USA): • 50 resources × 100ms = 5 seconds • User leaves after 3 seconds With CDN (edge in Moscow): • 50 resources × 5ms = 250 ms • Page loads instantly Improvement: 20x!
Why does CDN reduce latency?
How CDN Works
A CDN consists of many **PoPs** (Points of Presence) - data centers around the world. Each PoP contains **edge servers** that cache content.
Key Components
| Component | Role | Example |
|---|---|---|
| PoP | Data center close to users | Cloudflare: 300+ PoPs |
| Edge Server | Caches and serves content | Nginx/Varnish |
| Origin | Source of truth, the origin server | AWS, DigitalOcean |
| Anycast | One IP → nearest server | BGP-level routing |
**Anycast**: A single IP address is announced from all PoPs. BGP automatically routes packets to the nearest one. It's like "any of these servers can respond".
What is a PoP in the context of CDN?
Push vs Pull CDN
How does content get to edge servers? Two approaches: **Pull** (lazy) and **Push** (eager).
Pull CDN (Lazy Loading)
Push CDN (Eager Loading)
| Criterion | Pull | Push |
|---|---|---|
| First request | Slow (miss) | Fast |
| Complexity | Simple | More complex |
| Control | Less | Full |
| Use case | Site static assets | Video, premieres |
**Pull CDN** is suitable for 95% of cases. Push is needed for critical content: movie premieres, live events, where the first request must be fast.
When is it better to use Push CDN?
Cache-Control Headers
CDN listens to HTTP headers from the origin. **Cache-Control** is the main tool for controlling caching behavior.
| Directive | Meaning | When |
|---|---|---|
| max-age | TTL in seconds | Primary approach |
| s-maxage | TTL for CDN (shared cache) | CDN TTL ≠ Browser TTL |
| public | Can be cached on CDN | Shared content |
| private | Browser cache only | User-specific data |
| no-store | Do not cache at all | Sensitive data |
| immutable | Content will not change | Versioned static assets |
| stale-while-revalidate | Serve stale, update async | Balance speed/freshness |
**Set-Cookie** in a response = CDN won't cache it! When cookies and caching are both required - use separate endpoints or the Vary header.
What is the difference between max-age and s-maxage?
CDN Invalidation
Updating content across 300+ edge servers around the world requires choosing from several strategies.
Content Hash (Best Practice)
Cache Purge API
Versioned URLs
**Best Practice for static assets**: Content hash (app.abc123.js) + max-age=1year + immutable. A purge is never needed - the file name simply changes.
| Method | Speed | Complexity | Use case |
|---|---|---|---|
| Content Hash | Instant | Medium | JS/CSS (build tools) |
| Purge API | Seconds-minutes | Simple | Images, infrequent updates |
| Versioned URL | Instant | Simple | When no build system |
Why is content hash (app.abc123.js) better than a query string (app.js?v=123)?
Key Takeaways
- **CDN** reduces latency through geographic proximity
- **Pull CDN** - lazy caching, suitable for most cases
- **Cache-Control** - the main tool for cache management
- **s-maxage** allows CDN to cache longer than the browser
- **Content hash** in the URL - best practice for static assets
- **Purge API** for emergency invalidation
Related Topics
CDN is part of the content delivery infrastructure
- Caching — CDN = edge cache, one of the caching levels
- Load Balancer — CDN includes geo-load balancing
- Message Queue — Async content updates on CDN
Вопросы для размышления
- CDN efficiently caches static content but is a poor fit for personalized responses. What architectural patterns allow serving millions of unique users with CDN still in the delivery chain?
- Invalidating CDN by URL poses a problem: old clients keep requesting stale URLs. How is this solved in production - cache-busting, versioned URLs, or Surrogate-Key tags?
- CDN adds an intermediate node to the delivery path. In which scenarios does CDN increase latency rather than reduce it - and how is this diagnosed?