Chapter 10 — CDN: Content Near You

A CDN (Content Delivery Network) stores copies of content in many locations around the world so many users can fetch it from a nearby edge — fast.

Why CDNs Exist

Two problems CDNs solve:

Latency: Light travels through fiber at ~200,000 km/s. A packet from Mumbai to Los Angeles (14,000 km round trip) takes at minimum 70ms just at the speed of light — plus routing overhead (~150ms in practice). A packet from Mumbai to a Mumbai server: ~1ms.

Origin load: Netflix has 200M subscribers. If every video request hit Netflix's origin servers in Los Angeles, the bandwidth and compute cost would be astronomical. CDN edge servers handle 95%+ of Netflix video traffic — origin servers only handle the small percentage of cache misses.

Without CDN:
  User in Mumbai → Netflix servers in LA → 150ms latency
  All 200M users → Netflix LA → overloaded

With CDN:
  User in Mumbai → CDN server in Mumbai → 1ms latency
  CDN serves 95% of requests → origin barely touched

How a CDN Works

Cache Hit — The Fast Path

User in Tokyo requests: GET /static/app.abc123.js

1. Request arrives at CDN edge POP in Tokyo.
2. Edge server checks its cache: FOUND ✓ (cache HIT)
3. Edge server returns cached response immediately.
4. Origin server is never contacted.

Latency: ~5ms (Tokyo user to Tokyo edge)

Cache Miss — The Slow Path (happens once per resource per POP)

User in Tokyo requests: GET /video/12345/chunk001.mp4  (not yet cached)

1. Request arrives at CDN edge POP in Tokyo.
2. Edge checks cache: NOT FOUND (cache MISS)
3. Edge makes request to Netflix origin servers (LA):
   Edge (Tokyo) → Origin (LA) → 150ms round trip
4. Origin returns the video chunk.
5. Edge caches it locally (stored on Tokyo edge SSD).
6. Edge returns response to user.

All subsequent users in Tokyo requesting the same chunk:
   Cache HIT → served from Tokyo edge → 5ms ✓

Cache Key

The CDN identifies what to cache using a cache key — typically the URL:

https://cdn.netflix.com/video/12345/chunk001.mp4
Cache key: /video/12345/chunk001.mp4

Same URL from different users → same cache key → same cached response ✓
Different URLs → different cache entries

Vary header extends the cache key with request headers:

Response: Vary: Accept-Encoding
Cache key becomes: /static/app.js + Accept-Encoding: br
               or: /static/app.js + Accept-Encoding: gzip
(Two separate cached copies — one per encoding)

Cache-Control and TTL

The origin server controls how long CDN caches a resource via Cache-Control headers:

Cache-Control: public, max-age=31536000, immutable
               ↑        ↑                 ↑
       Anyone can cache  1 year TTL     Never revalidate
       (CDN, browser)

Use for: /static/app.abc123.js  (hash in filename = content-addressed)
         If content changes, the filename changes — old URL can stay cached
         until its long TTL expires.

Cache-Control: no-store
Use for: / (home page — personalized, never cache)
         /api/users/me  (user-specific data)

Cache-Control: public, s-maxage=3600, max-age=0
               ↑              ↑           ↑
       CDN can cache  CDN caches 1hr  Browser: don't cache
       s-maxage is for shared caches (CDN).
       max-age is for private caches (browser).

CDN Cache Invalidation

A cached file has a TTL. What if you need to invalidate it before TTL expires?

Scenario: You deployed a bug fix in app.js but cached version is served for 24hrs.

Solutions:

1. Content-addressed filenames (best):
   app.abc123.js → app.def456.js  (new hash = new URL = new cache entry)
   Old URL expires naturally. New URL has no cached version → cache miss → fresh.
   Zero invalidation needed.

2. CDN API purge:
   POST /cdn-api/purge  {"paths": ["/static/app.js"]}
   CDN removes from all POPs immediately.
   Useful for urgent security fixes.

3. Surrogate keys / cache tags:
   Response header: Cache-Tag: product-12345, category-electronics
   Purge all resources tagged "product-12345" with one API call.
   Cloudflare, Fastly, and Akamai support this.

4. Version query strings:
   /app.js?v=2  (different URL = different cache entry)
   Old: /app.js?v=1  (cached, expires naturally)
   New: /app.js?v=2  (fresh, cache miss initially)

Netflix Open Connect (OCA)

Netflix operates their own CDN called Open Connect with custom-built OCA (Open Connect Appliances) — physical servers installed directly inside ISP networks worldwide.

Why Netflix Built Their Own CDN

Netflix has historically represented a large share of downstream internet traffic in many reports. Third-party CDN costs at that scale would be enormous. Open Connect lets Netflix:

• Control the hardware (optimized for video streaming)
• Negotiate free peering with ISPs (mutual benefit — ISPs don't pay transit for Netflix traffic)
• Pre-position content proactively (fill servers during off-peak hours)

How Netflix OCA Works

Netflix OCA Architecture:
                    Netflix HQ (LA/Oregon)
                    Origin + Management Plane
                           │
                    BGP + Control Plane
                    ┌──────┼──────┐
                    │      │      │
              ┌─────┘  ┌───┘  ┌──┘
              │        │      │
         ┌────▼──┐ ┌───▼──┐ ┌▼──────┐
         │ Comcast│ │ AT&T │ │ Tata  │
         │ IXP   │ │ IXP  │ │ Mumbai│
         │ OCA   │ │ OCA  │ │ OCA   │
         └───────┘ └──────┘ └───────┘
              ↑         ↑         ↑
         Physically     Physically  Physically
         installed in   installed   installed in
         Comcast's DC   in AT&T's   Tata's DC
                        network     (Mumbai)

User in Mumbai → Tata network → OCA at Tata Mumbai → video served locally
Never leaves Tata's network. No transit cost. Ultra-low latency.

OCA Content Fill Strategy

OCA servers are filled proactively during off-peak hours (3–6 AM local time) using Netflix's proprietary proactive caching:

Netflix's data team predicts: "Squid Game Season 3 will be top 10 in India tomorrow"
Night before release:
  Netflix fills all India OCAs with Squid Game S3 (all quality levels)

Day of release:
  User in India: GET /video/squid-game-s3-ep1/4k/chunk001
  OCA in India: HIT → serves from local storage
  0 bytes travel from US to India ✓

Push vs Pull CDN

Pull CDN (most common)

CDN pulls content from origin on first request (cache miss). Content is fetched on-demand.

First request: CDN → Origin (slow)
Subsequent requests: CDN cache → User (fast)

Good for: unknown access patterns, large catalogs, long-tail content.

Push CDN

Content is proactively pushed to CDN by the origin — before any user requests it.

You upload a new movie to Netflix:
  Netflix push → all CDN/OCA POPs worldwide receive the file
  First user request: already cached → fast ✓

Good for: predictable popular content, time-sensitive launches. Netflix has described proactive content placement for popular titles as a core part of Open Connect's design.

CDN and TLS

CDN providers hold your TLS certificate and serve your users. Two models:

1. Shared certificate (multi-tenant CDN):

CDN presents a cert for *.cdn-provider.com
Your content served from cdn1234.cloudfront.net
Users see Cloudfront's cert, not your cert.

2. Custom domain + cert:

CDN serves: https://cdn.netflix.com
CDN holds netflix.com wildcard certificate ✓
Users see netflix.com cert — seamless.
Netflix uploads their cert to CDN (or CDN uses Let's Encrypt / ACM automatically).

3. Keyless SSL:

CDN doesn't hold your private key.
During TLS handshake, CDN sends key operations to your origin key server.
Your private key operation stays under your control instead of being uploaded
to the CDN.
Cloudflare offers this ("Keyless SSL").

CDN for APIs vs Static Assets vs Video