Content Delivery Network

Problem Statement & Requirements

Design a globally distributed Content Delivery Network that caches and serves static and dynamic content from edge locations closest to users — similar to CloudFront, Cloudflare, Akamai, or Fastly.

Functional Requirements

• Cache and serve static assets — images, videos, CSS, JS, fonts, HTML pages
• Support dynamic content acceleration — API responses, personalized pages via edge compute
• Content purge / invalidation — origin can invalidate cached content globally within seconds
• Custom domain support — customers bring their own domains with TLS (SNI-based)
• TLS termination at the edge — HTTPS everywhere, automatic certificate management
• Origin shielding — collapse multiple edge requests into a single origin fetch
• Geo-restriction — block or allow content by country/region
• Real-time analytics — hits, misses, bandwidth, latency, error rates per PoP
• Edge compute — run lightweight functions (like Cloudflare Workers) at the edge

Non-Functional Requirements

• Ultra-low latency — serve cached content in < 10 ms (p50), < 50 ms (p99) globally
• High availability — 99.999% uptime (< 5 min downtime/year)
• Massive throughput — handle 100M+ requests/second globally
• Global reach — 200+ Points of Presence (PoPs) across 50+ countries
• Cache hit ratio — target > 95% for static content
• Instant purge — invalidate content globally within < 5 seconds
• DDoS protection — absorb multi-Tbps volumetric attacks at the edge

Out of Scope

• Full WAF (Web Application Firewall) rule engine details
• Detailed DNS infrastructure design (covered as a component, not the focus)
• Video live-streaming specific protocols (HLS/DASH segmentation)

Scale Estimations

Traffic

Bandwidth

Storage (Per PoP)

Hardware Estimate (Per PoP — Medium Tier)

This first layer defines the system boundary. The next chapters add application logic and data dependencies. After examining the request paths and tradeoffs, we will add operational safeguards and bring the complete architecture together.

API Design

Customer Configuration API

POST /api/v1/distributions
Content-Type: application/json

Request:
{
  "name": "my-website-cdn",
  "origins": [
    {
      "domain": "origin.example.com",
      "protocol": "https",
      "port": 443,
      "path": "/assets",
      "weight": 100,               // for origin failover / load balancing
      "timeout_ms": 30000,
      "retry_count": 2
    }
  ],
  "domains": ["cdn.example.com", "assets.example.com"],
  "cache_behaviors": [
    {
      "path_pattern": "/images/*",
      "ttl_seconds": 86400,         // 24 hours
      "compress": true,
      "allowed_methods": ["GET", "HEAD"],
      "cache_key_includes": ["query_string", "accept_encoding"]
    },
    {
      "path_pattern": "/api/*",
      "ttl_seconds": 0,             // pass-through to origin
      "allowed_methods": ["GET", "POST", "PUT", "DELETE"],
      "forward_headers": ["Authorization", "Accept"]
    }
  ],
  "tls": {
    "certificate": "auto",          // auto-provision via Let's Encrypt
    "min_protocol_version": "TLSv1.2",
    "http2": true
  },
  "geo_restriction": {
    "type": "whitelist",
    "countries": ["US", "CA", "GB", "DE", "JP"]
  }
}

Response (201 Created):
{
  "distribution_id": "d-abc123",
  "status": "deploying",
  "cdn_domain": "d-abc123.cdn.net",
  "custom_domains": ["cdn.example.com"],
  "created_at": "2026-04-03T10:00:00Z",
  "estimated_deploy_time_seconds": 120
}

Purge / Invalidation API

POST /api/v1/distributions/{distribution_id}/invalidations
Content-Type: application/json

Request:
{
  "paths": [
    "/images/hero.jpg",           // exact path
    "/css/*",                     // wildcard
    "/*"                          // purge everything (use sparingly)
  ]
}

Response (202 Accepted):
{
  "invalidation_id": "inv-xyz789",
  "status": "in_progress",
  "paths": ["/images/hero.jpg", "/css/*"],
  "created_at": "2026-04-03T10:05:00Z",
  "estimated_completion_seconds": 5
}

Analytics API

GET /api/v1/distributions/{distribution_id}/analytics
    ?start=2026-04-03T00:00:00Z
    &end=2026-04-03T23:59:59Z
    &granularity=1h
    &metrics=requests,bandwidth,cache_hit_ratio,p99_latency

Response (200 OK):
{
  "distribution_id": "d-abc123",
  "data_points": [
    {
      "timestamp": "2026-04-03T00:00:00Z",
      "requests": 45000000,
      "bandwidth_gb": 2250,
      "cache_hit_ratio": 0.967,
      "p99_latency_ms": 28,
      "error_rate_4xx": 0.012,
      "error_rate_5xx": 0.0003
    },
    ...
  ]
}

Data Model

Distribution Configuration

Cache Entry (Per Edge Server — In-Memory/On-Disk)

Access Log Record (Streamed to Analytics)

Core Design Decisions

Decision 1: Request Routing — How Users Reach the Nearest PoP

This is the most critical decision. Every request must land on the optimal PoP.

Option A: DNS-Based GeoDNS

Option B: Anycast IP Routing

Option C: Hybrid (DNS + Anycast) — Recommended

Decision 2: Cache Hierarchy — Multi-Tier Caching

Decision 3: Cache Invalidation Strategy

Detailed Flow Diagrams

Cache Hit Flow (Happy Path — 95% of Requests)

Cache Miss Flow (with Origin Shield)

Purge / Invalidation Flow

A popular object expiring at many edges can send a wave of simultaneous misses to the origin. Collapse concurrent requests for the same object and consider staggered expiry or permitted stale serving. The cache key must include the request attributes that change the representation; otherwise one person’s response can be served to another.

TLS at the Edge

TLS Termination Architecture

OCSP Stapling

Traditional OCSP:
  Client → CDN → serve content
  Client → CA's OCSP responder → "is cert still valid?"  (SLOW, privacy leak)

OCSP Stapling:
  CDN periodically fetches OCSP response from CA
  CDN staples (attaches) OCSP response to TLS handshake
  Client gets cert + validity proof in one step → faster, more private

Edge Compute

Architecture

Edge Compute Deployment Flow

DDoS Mitigation at the Edge

Handling Edge Cases

Thundering Herd (Cache Stampede)

Problem: Popular object expires → 10,000 concurrent requests all miss cache
         → all 10,000 hit origin simultaneously → origin overload

Solution: Request Coalescing (aka Request Collapsing)

  Request 1 (cache miss) → lock: I'll fetch from origin
  Request 2 (cache miss) → wait, someone is already fetching
  Request 3 (cache miss) → wait, someone is already fetching
  ...
  Request 10,000 (cache miss) → wait

  Origin receives: 1 request (not 10,000)
  Response returns → populate cache → serve all 10,000 waiters

  Implementation: per-cache-key mutex with a wait queue
  Timeout: if origin is slow (> 5s), serve stale content if available

Stale Content During Origin Failure

Problem: Origin is down → cache misses can't be filled → users get errors

Solution: Stale-If-Error

  Cache-Control: max-age=60, stale-if-error=86400

  Normal: serve fresh content (age < 60s)
  Origin down: serve stale content (age < 86400s) + add Warning header
  Completely expired: return 502/504 with custom error page

  Edge behavior:
  1. Cache miss → try origin → timeout/5xx
  2. Check stale cache → if stale copy exists, serve it
  3. Add header: Warning: 110 "Response is Stale"
  4. Log origin failure → alert monitoring

Hot Object / Viral Content

Problem: One object (e.g., breaking news image) gets 1M RPS at a single PoP

Solution: Multi-layer approach
  1. RAM cache (L1) absorbs most reads — kernel-level serving (io_uring / sendfile)
  2. If single server saturates → PoP-level LB distributes across all servers
  3. All servers in PoP independently cache the object (no shared cache needed)
  4. Pre-warm: detect virality (rapid access count increase) → proactively
     push to all PoPs before they miss

  Key insight: CDN edge servers are embarrassingly parallel for reads.
  Unlike databases, every server can independently cache + serve the same object.

Cache Poisoning

Problem: Attacker sends crafted request → poisoned response gets cached
         → all subsequent users get the poisoned response

Attack: GET /page HTTP/1.1
        Host: cdn.example.com
        X-Forwarded-Host: evil.com      ← if origin reflects this, cached for all users

Mitigations:
  1. Strict cache key construction — only include documented Vary headers
  2. Never cache responses with Set-Cookie headers
  3. Strip untrusted headers before forwarding to origin
  4. Validate Cache-Control directives from origin (ignore private/no-store only for intended objects)
  5. Cache key includes Host header — prevents cross-domain poisoning
  6. WAF rules to detect header injection attempts

Partial Content / Range Requests (Video Seeking)

Client: GET /video.mp4
        Range: bytes=1000000-2000000

Edge behavior:
  Option A: Cache full object, serve range from cache
    + Simple — one cached copy serves any range
    - Wastes bandwidth on first fetch if user only watches 30s of a 2-hour video

  Option B: Cache range slices (e.g., 1 MB chunks)
    + Only fetch what's needed
    - Complex cache management, many small cache entries
    - Reassembly overhead

  Recommended: Hybrid
    → Small objects (< 10 MB): cache full object
    → Large objects (> 10 MB): cache in fixed-size slices (2 MB)
    → Use internal Range requests to origin for slices
    → Serve client's Range from assembled slices

Tradeoffs & Design Decisions Summary

Reliability & Fault Tolerance

Single Points of Failure & Mitigations

Graceful Degradation Hierarchy

Level 1 (single server failure):
  → LB routes around it. Zero user impact. Auto-heals.

Level 2 (partial PoP degradation):
  → Remaining servers absorb traffic. Increased latency at that PoP.
  → Alert ops team.

Level 3 (full PoP failure):
  → BGP withdrawal in ~30s. Users rerouted to next-closest PoP.
  → Latency increases by ~10-50 ms. No data loss.

Level 4 (origin shield failure):
  → Edges bypass shield, fetch directly from origin.
  → Origin sees higher load but still functional.

Level 5 (customer origin failure):
  → Serve stale cached content (stale-if-error).
  → Custom error pages for truly uncached content.
  → Alert customer via webhook.

Level 6 (control plane failure):
  → Edges continue serving with last-known config.
  → No config updates or purges until control plane recovers.
  → Edge-to-edge gossip for critical updates (if implemented).

High-Level Architecture

Component Breakdown

Full System Architecture (Production-Grade)

Publish a new application release containing HTML and versioned JavaScript files. Decide which files may be cached for a long time and which need rapid revalidation. Then roll back. A good cache policy should let both old and new HTML find the assets they reference throughout the transition.

Interview Tips

1. Start with the two-sentence pitch — "A CDN is a globally distributed cache. It serves content from the edge closest to users, reducing latency from ~200 ms (origin) to ~5 ms (edge cache hit)."

2. Draw the DNS → Edge → Shield → Origin hierarchy first — This is the backbone. Explain each tier's purpose and cache hit contribution.

3. Discuss Anycast deeply — Most candidates only mention DNS routing. Explain how Anycast works (same IP, BGP announces from every PoP), why it's elegant (automatic failover, DDoS dilution), and its limitations (TCP connection breaks on route change).

4. Cache key construction is subtle — Don't handwave. Explain how the cache key is built from path + query + Vary headers + distribution ID. Mention cache poisoning risks.

5. Explain the thundering herd problem and request coalescing — This shows you've thought about real production issues, not just the happy path.

6. Stale-while-revalidate is a killer feature — Explain the tradeoff: users always get fast responses, content is at most one cycle stale, and origins never block the user.

7. TLS at the edge is non-negotiable — Quantify: terminating TLS at edge vs origin saves 1-2 RTTs × distance. For a user 200 ms from origin but 5 ms from edge, that's 390 ms saved on TLS 1.2.

8. Mention edge compute — This differentiates you. Explain V8 isolates (sub-ms cold start), use cases (A/B testing, auth, geolocation), and why they're superior to containers for request-level compute.

9. Discuss cost model — CDN economics matter. Bandwidth is the main cost (peering vs transit). Explain why CDNs negotiate private peering with ISPs and why edge cache capacity planning uses power-law distributions.

10. End with DDoS — "A CDN is inherently a DDoS mitigation layer. With 250 PoPs each handling Tbps, the network absorbs attacks by distributing them. The origin never sees the attack traffic."