Cheat Sheet
Key takeaway
A CDN solves distance, not repetition. Edge servers near users cut propagation delay, stop the origin sending identical bytes once per user, and remove the single point of failure — which is why it's an architecture, not an optimization.
Key terms
| Term | One line |
|---|---|
| Edge server / proxy | Caching server at the network edge, near users |
| PoP | Point of presence — a location holding numerous proxy servers |
| Origin server | Source of truth; serves what the CDN doesn't have |
| Routing system | Decides which edge serves a given client |
| Distribution system | Moves content from origin out to the edges |
| Scrubber servers | Filter malicious traffic (DDoS) before it reaches proxies |
| IXP | Internet exchange point — where networks interconnect |
| TTR | Time-to-refresh — polling interval in the pull model |
| ESI | Edge Side Includes — markup marking which page parts are dynamic |
| OCA | Netflix's Open Connect Appliance |
Cache ≠ CDN. A cache reduces repeated work; a CDN reduces distance.
Why a CDN is mandatory at scale
Latency US East -> US West = 62.9 ms
US East -> Cape Town = 225.63 ms (VoIP budget is 150 ms)
Bandwidth Origin must send the same bytes once PER USER
250k req/sec * 500 KB * 8 = 1 Tbps sustained from one origin
Failure One data center = one single point of failure
Components
| Component | Job |
|---|---|
| Clients | Request content |
| Routing system | Direct clients to the optimal facility (placement, volume, load, URI namespace) |
| Scrubbers | Separate legitimate from malicious traffic |
| Proxy servers | Serve content — hot in RAM, cold on SSD/disk |
| Distribution system | Push content from origin to edges |
| Origin servers | Source of truth + mapping metadata |
| Management system | Latency, downtime, packet loss, load, billing |
Key detail: distribution feeds cache state back to routing, so routing picks an edge on availability, not just proximity.
Functional ops: retrieve · request · deliver · search · update · delete Non-functional: performance · availability (incl. DDoS) · scalability · reliability + security Building blocks reused: DNS (routing) · load balancers (intra-PoP distribution)
Push vs pull
| Push CDN | Pull CDN | |
|---|---|---|
| Initiated by | Origin server | First user request |
| Managed by | Content provider | The CDN |
| Replicas | More — better availability | Fewer |
| Storage | Higher | Lower |
| First-request latency | Fast | Slow (origin round trip) |
| Changing content | Poor — redundant pushes | Good |
| Best for | Static assets, predictable demand | Dynamic content, large catalogues |
Most providers use a hybrid. Push the stable and universally-needed; pull the long tail. Pull's weakness: cold start — first user per region pays origin latency. Fix with cache warming + tiering.
Dynamic content
| Technique | What it does |
|---|---|
| Edge scripting | Run scripts at the proxy using location, time, third-party APIs |
| Compression | e.g. Cloudflare Railgun — shrinks the origin-to-proxy leg |
| ESI | Cache the static shell, fetch only dynamic fragments; not a W3C standard but widely used |
| DASH / HLS | Manifest of URIs per resolution; each resolution is a cacheable static object |
Rule: compute at the edge when inputs are the request itself. Keep it at origin when inputs are shared mutable state.
Multi-tier hierarchy
Origin -> Parent proxies -> Edge proxies -> Clients (typically one or two tiers)
The arithmetic: 1,000 edges miss the same object → 1,000 origin requests flat, or 20 with a parent tier = 50x reduction.
Long tail: few items get most requests; a long tail gets few each. → Head in edge RAM, tail on parent disk. Multi-layer cache handles the tail.
Failures: child fails → DNS routes elsewhere · parent fails → child knows many parents · origin fails → hot backups + replicated store.
Request routing
"Nearest" = network distance (path length + bandwidth) + request load — NOT geography.
| Mechanism | Who decides | Converges | Weakness |
|---|---|---|---|
| DNS redirection | CDN authoritative DNS | Minutes (TTL) | Slow failover; resolver caching skews load; resolver ≠ user location |
| Anycast | The network (BGP) | Fast | Less precise load control |
| HTTP redirection | Origin (302 + Location) | Immediate | Costs a full origin round trip first |
| Client multiplexing | The client | Immediate | Client lacks load/health info — picks badly |
DNS redirection has two steps: map client → location, then load-balance within the PoP. Short TTLs at step 2 allow shifting clients. Used by Akamai.
Consistency
| Mechanism | Direction | Staleness | Cost |
|---|---|---|---|
| Periodic polling (TTR) | Proxy asks on a schedule | Up to one TTR | Wasted bandwidth when content rarely changes |
| TTL | Proxy revalidates on expiry, when requested | Up to the TTL | One revalidation per expiry, only for requested objects |
| Leases | Origin notifies the proxy | Near zero | Origin must track outstanding leases; adaptive leasing tunes duration |
TTL bounds staleness — it does not deliver freshness. Takedowns and mispricing need explicit purge. Stampede risk: identical TTLs synchronize revalidation. Use jittered TTLs + request coalescing.
Deployment
| Strategy | Where | Suits |
|---|---|---|
| On-premises | Small data centers near IXPs | Volatile or vast catalogues (Google) |
| Off-premises | Inside ISP networks — one hop from users | Large but stable catalogues (Akamai, Netflix) |
Split TCP: terminate client connections at a nearby edge (cheap handshake, fast ramp), forward over persistent, large-window connections to origin — helps even for uncached content. Predictive push: proactively move content closer based on forecast demand. Tools: ProxyTeller (hit ratio, bandwidth, latency); greedy / random / hotspot algorithms.
Why ISPs accept the box: cuts their external bandwidth bill · improves customer responsiveness · reduces internet-core traffic.
Build vs buy
Public CDN risks: outages outside your control · coverage gaps · blocking from shared domains/IPs due to other customers' content.
Netflix Open Connect — OCAs store no user data; they report health/routes/available files to a control plane in AWS and serve content directly. Why they built it: scalability · cost · security · control · diagnostics · retention. Hit ratio ~95%.
Build only when: your volume distorts provider pricing and the catalogue supports a high hit ratio. Otherwise buy. Even when building, keep a public CDN for overflow and failure.
Quick decision cues
- Global users + one origin → CDN is mandatory, not optional
- Stable, universally-needed assets → push
- Large or fast-changing catalogue → pull
- Mostly-static page with a personalized strip → ESI
- Response depends only on the request → edge scripting
- Needs authoritative shared state → keep at origin
- Thousands of edges, one origin → add a parent tier
- Need fast failover → anycast, not DNS
- Must disappear immediately → purge, not TTL
- Stable catalogue, latency critical → place inside ISPs
- Not Netflix-scale → buy
Work the Interview Walkthrough for the full design and the Concept Drills for rapid-fire practice.