Concept Drills: 16 CDN Probes

CDNs show up as a follow-up in almost every large design. These are the probes that actually get asked.

Fundamentals

1. What's the difference between a cache and a CDN? · L5 · Testing: precision

Different axes. A cache stores frequently accessed data closer to the application or user to reduce repeated work and backend load. A CDN distributes content across geographically dispersed edge servers to reduce network latency. A cache in your data center does nothing for a user in Cape Town — the request still crosses an ocean to reach it.

2. Why can't you just add more origin capacity instead? · L5 · Testing: the physics argument

Because the binding constraint isn't capacity, it's distance. US East to Cape Town is about 225 ms round trip, which already blows a 150 ms real-time budget before any server does work. That's the speed of light. And separately, the origin would have to send the same bytes once per user — bandwidth scales linearly with users while the content is identical.

3. Does a CDN cache everything from origin? · L5 · Testing: content shape

No — a considerable portion, mostly static, depending on capability and volume. Netflix can hold more than 90% of its movies at the edge because the catalogue is bounded and demand is concentrated. YouTube can't, because the catalogue is effectively unbounded and most videos are watched almost never. That difference drives the whole caching strategy.

Caching models

4. Push or pull CDN? · L5 · Testing: whether they split by content type

Both, split by content type. Push for static, stable, universally-needed assets — the origin knows what to send and redundant pushes aren't a problem when content rarely changes. Pull for large or frequently-changing catalogues, where pushing everything wastes storage on content nobody requests. Most providers run the hybrid.

5. What's the weakness of pure pull? · Staff · Testing: the cold start

The first request in every region pays a full origin round trip — exactly the latency the CDN exists to eliminate. At a launch that means the first user in each PoP gets the worst experience simultaneously. Mitigations are cache warming before known events and tiered caching, so a miss hits a regional parent rather than the origin.

6. How do you cache a personalized page? · Staff · Testing: dynamic content

Decompose it. Most of the page is stable — header, nav, layout — with a small personalized region. ESI lets the edge cache the shell and fetch only the dynamic fragment, so most of the page caches despite the page being "dynamic." For responses depending only on the request itself — location, time, headers — edge scripting computes at the edge with no origin call. Anything needing authoritative shared state stays at origin.

Architecture

7. Why do CDNs use a multi-tier hierarchy? · Staff · Testing: the arithmetic

Because cache misses aggregate. A thousand edges missing the same new object is a thousand origin requests; with twenty parents between them it's twenty, each serving fifty edges — a 50x reduction in origin load from one tier. It also gives the long tail a home: head content in edge RAM, tail content on parent disk shared across edges, so no edge stores what it serves twice a month.

8. What's the long tail and why does it matter here? · L5 · Testing: content distribution

A handful of items get most requests, followed by a very long tail of rarely-requested content. It matters because the head fits in edge RAM and serves nearly all traffic cheaply, while the tail is collectively significant but individually rare — so caching all of it at every edge is hugely wasteful. That's what the multi-layer cache and the RAM/disk split inside each proxy exist to solve.

9. What happens when a parent proxy fails? · L5 · Testing: failure paths

Each child knows several upper-layer parents and switches to another. Same pattern at every tier: DNS routes clients away from a failed child, and the origin is a set of servers with hot backups behind a replicated store. The design point is that no tier has a single upstream whose loss orphans it — otherwise tiering just trades one bottleneck for several.

Routing

10. How does a client find the nearest edge? · L5 · Testing: the mechanism

Usually DNS redirection: the client resolves the name, gets pointed at the CDN's authoritative DNS, which returns an edge IP based on the resolver's location and current load. Then intra-PoP load balancing picks the specific proxy — global tier picks the region, local tier picks the server.

11. Does "nearest" mean geographically closest? · Staff · Testing: a common wrong reflex

No. It's network distance — path length and available bandwidth — plus current request load. A server 200 km away on an uncongested fat link beats one 50 km away behind a saturated peering point. And an overloaded nearby proxy is worse than a slightly more distant idle one.

12. Compare the four routing mechanisms. · Staff · Testing: breadth

DNS redirection — the workhorse, used by Akamai; TTL-bound so failover takes minutes, and skewed by resolver caching. Anycast — all edges share one IP and BGP routes to the nearest; converges far faster but gives up precise load control. HTTP redirection — simplest, but costs a full origin round trip before the client learns where to go. Client multiplexing — the client picks from a candidate list, which is inefficient because the client lacks the load and health information to choose well.

Consistency and operations

13. TTL versus periodic polling? · L5 · Testing: the efficiency argument

Polling is time-driven — it revalidates on a schedule whether or not anyone wants the object, wasting bandwidth when content rarely changes. TTL is request-driven — an expired object is only revalidated when someone actually asks. For a long tail of rarely-requested content that difference is enormous.

14. What are leases, and what do they cost? · Staff · Testing: the inversion

The origin grants a lease promising to notify the proxy of changes for some interval; the proxy renews on expiry. It inverts the direction — origin-driven rather than proxy-driven — so freshness is near-immediate instead of bounded by expiry. The cost is that the origin must track every outstanding lease, which is real state and exactly the coordination CDNs otherwise avoid. Adaptive leasing tunes the duration by proxy load to bound that.

15. You invalidate a popular object and origin falls over. Why? · Staff · Testing: the stampede

Thundering herd — every edge misses at once and stampedes origin. The hierarchy absorbs much of it since parents deduplicate, but I'd add request coalescing so N concurrent misses for the same object become one upstream fetch. And I'd jitter TTLs, because identical expiry times across edges synchronize the stampede — same reasoning as jittered retries.

16. Build your own CDN or buy one? · Staff · Testing: economic judgment

Buy, unless your traffic volume distorts provider pricing and your catalogue supports a very high hit ratio. Netflix built Open Connect because commercial providers couldn't scale fast enough, cost became prohibitive, and they wanted end-to-end control — and they hit 95% because the library is bounded. Note they built the data plane but ran the control plane on AWS: build where your cost curve is unusual, buy where it isn't. And they still keep public CDNs for overflow and failure.

Self-check

The cheat sheet next compresses the chapter onto one page.