Why CDNs Exist

Why this matters: the Back-of-the-Envelope chapter showed that a cross-continent round trip is near the speed-of-light floor. No amount of engineering fixes that. A CDN is the architectural answer: stop making the trip.

Key takeaway

A data-intensive application serving millions of global users from a single data center faces three problems it cannot engineer away: high latency, data-intensive workloads, and resource scarcity with failure risk.

Problem 1: high latency

Physical distance between clients and servers increases user-perceived latency. Total latency has four components:

Component	What it is
Transmission delay	Limited by bandwidth — how fast bits can be pushed onto the link
Propagation delay	Signal travel time — bounded by physics, not budget
Queuing delay	Network congestion along the path
Processing delay	Time spent in routers and servers handling the packet

Real-time applications such as VoIP typically require end-to-end latency below 150 ms. Video streaming tolerates more but degrades with multi-second latency.

Problem 2: data-intensive workloads

Transferring large volumes over long distances traverses multiple ISPs and network paths. Throughput suffers from variable congestion and smaller path MTU sizes along the way.

The deeper problem is redundancy: the origin server must transmit the same data individually to every client. Bandwidth usage scales linearly with users while the content stays identical.

1 million users each fetch the same 5 MB video
Origin transmits:  1,000,000 * 5 MB = 5 TB

...of which 4,999,995 MB is the same bytes, sent again.

Problem 3: resource scarcity and failure risk

A single data center has finite compute, storage, and network capacity. As traffic grows those resources become bottlenecks.

It is also a single point of failure. If the data center goes offline through outage or disaster, the service is simply unavailable — the availability ceiling from the Foundations module, imposed by geography.

The solution

A content delivery network brings data closer to users around the world — converting a distance problem into a placement problem.

Each problem gets a matching answer: latency falls because the content is nearby; bandwidth stops multiplying because the origin sends each object once per edge rather than once per user; and failure risk drops because there is no longer a single place for everything to live.

Key takeaway

A CDN is not a performance optimization bolted onto a working system. For a global, data-intensive service it is the only architecture that satisfies the latency requirement at all — because the alternative is bounded by the speed of light.

What this chapter builds

Interview signal by level

Level	What a strong answer sounds like
L4	"We'd put a CDN in front to make it faster."
L5	Names the mechanism: "a CDN caches content near users, so requests don't cross the ocean and the origin isn't sending the same bytes a million times."
Staff+	Frames it as a hard constraint: "US East to Cape Town is about 225 ms round trip, which already exceeds a real-time budget — that's physics, not tuning. A CDN isn't an optimization here, it's the only architecture that meets the requirement."

Next: what exactly we're building.