Interview Walkthrough: Design a CDN

"Design a content delivery network."

CDNs appear in two forms: as the whole question, and — far more often — as one box inside a larger design that the interviewer suddenly asks you to open. This walkthrough prepares you for both.

Step 0 — Scope it before you design

• What content are we serving — static assets, video, dynamic pages, or a mix?
• How large is the catalogue, and how concentrated is demand?
• Where are the users, and where is the origin?
• How fresh must content be — can it be seconds stale? Minutes?
• Do we need to purge content immediately (takedowns, mispricing)?
• Are we building this, or designing a service others use?

Then commit:

"I'll design a general-purpose CDN serving mostly static assets and video, with a large catalogue and concentrated demand. Users are global, the origin is in one region. Content can be seconds-to-minutes stale, but we need an immediate purge path. Let me size it first, because I want to show why this is mandatory rather than optional."

Step 1 — A BOTEC that proves necessity

Users                     = 500M globally
Requests per user per day = 50 assets
Average asset size        = 500 KB

Requests/day = 500M * 50            = 25 billion
Requests/sec = 25B / 100,000        = 250,000/sec

Without a CDN, egress from origin:
  250,000 * 500 KB * 8              = 1,000 Gbps = 1 Tbps sustained

With a 95% edge hit ratio:
  Origin egress                     = 50 Gbps

"One terabit per second sustained from a single origin isn't a cost problem, it's an impossibility — and that's before the latency argument. At a 95% hit ratio the origin carries 50 Gbps, which is ordinary. That's the whole justification, and it took fifteen seconds."

Step 2 — Requirements

Functional: retrieve · request · deliver · search · update · delete. Non-functional: performance (minimize latency) · availability (including during DDoS) · scalability (horizontal) · reliability and security (no SPOF).

Say the framing: "Six operations, and note that retrieve and deliver are the same movement in opposite directions — that's push versus pull, and it's the first real decision."

Step 3 — Components

"The two components worth dwelling on are the routing system and the distribution system — and the feedback between them. Distribution tells routing what content is where, so routing can pick an edge on cache state as well as proximity. Without that, we happily send users to a nearby edge that has to fetch from origin anyway."

Step 4 — Caching strategy

"Split by content type. Static assets — logo, CSS, product images — get pushed: small, stable, needed by every page, and pushing guarantees the first visitor in each region gets a hit. The article and video catalogue gets pulled, because most items are rarely requested and pushing everything wastes storage on content nobody reads. Most real providers run this hybrid."

Then pre-empt the follow-up:

"Pure pull has a cold-start problem — the first user in every region eats an origin round trip, which for a launch means everyone's first impression is the slow path. So I'd warm the cache before known events and rely on tiered caching so a miss hits a regional parent, not the origin."

Step 5 — The hierarchy

"One or two tiers between edges and origin. The arithmetic: 1,000 edges all missing the same new object is 1,000 origin requests flat; with 20 parents it's 20, and each parent serves 50 edges. 50x reduction in origin load from one tier.

It also gives the long tail somewhere to live. Head content sits in edge RAM; tail content sits on parent disk shared across many edges — so no edge stores an object it serves twice a month."

Step 6 — Routing

"DNS redirection as the workhorse: the client resolves our 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 actual proxy — global tier picks the region, local tier picks the server.

Two caveats I'd state. 'Nearest' means network distance and load, not geography — a fatter uncongested path beats a shorter congested one. And DNS is TTL-bound, so failover takes minutes with a long tail; where I need fast failover I'd use anycast and let BGP converge instead."

Step 7 — Consistency

"TTL as the default: each object gets an expiry, and on the next request after expiry the proxy revalidates — if unchanged, it resets the TTL and keeps serving. That's request-driven rather than time-driven, which matters enormously for a long tail nobody is requesting.

But TTL can't handle a takedown or a mispriced product, so I also need an explicit purge path. And if I needed near-immediate freshness broadly, leases invert it — the origin promises to notify holders — at the cost of the origin tracking every outstanding lease."

Deep Dives & Follow-up Questions

"How do you serve personalized pages from a CDN?"

Decompose the response rather than giving up on caching. Most of a page is stable — header, nav, layout, images — with a small personalized region. Edge Side Includes let the edge cache the static shell and fetch only the dynamic fragment from origin, so 95% of the page caches even though the page is "dynamic." For responses that depend only on the request itself — location, time, headers — I'd use edge scripting and compute at the edge with no origin involvement at all. What I would not put at the edge is anything needing authoritative shared state, like inventory or a balance: an edge with stale data gives fast, confidently wrong answers.

"A cache miss storm hits when you invalidate a popular object. What happens?"

Every edge misses simultaneously and stampedes the origin — the thundering herd. The hierarchy absorbs most of it, since edges hit parents and parents deduplicate, but I'd also want request coalescing at each tier so N concurrent misses for the same object become one upstream fetch, with the rest waiting on it. Staggered TTLs help too: identical expiry times across edges synchronize the stampede, so adding jitter to TTL spreads revalidation out. Same reasoning as jittered retries from the Foundations module.

"How do you handle a DDoS?"

The CDN is the natural place, because it terminates enormous traffic close to the source and far from origin. Scrubber servers filter malicious traffic before it reaches edge proxies, engaged when an attack is detected. Beyond that, the CDN's distributed capacity is itself the defense — an attack that would flatten one origin gets spread across hundreds of PoPs. And because the origin's address isn't what clients resolve, the origin is largely hidden behind the edge.

"An edge serves stale content after you fixed a bug. Diagnose it."

Check the TTL that was set on the object and how much of it remains — the object may simply not have expired, in which case it's working as configured and the fix is a purge. If a purge was issued, verify it actually propagated to every PoP; purge is a distributed operation and can partially fail. Also check whether a parent cache still holds the old version, since an edge revalidating against a stale parent gets stale confirmation. And confirm the client isn't holding its own browser cache copy, which no amount of CDN purging touches.

"Where does this design cost the most money?"

Egress bandwidth, by a wide margin — which is why the hit ratio is the number that matters. Going from 90% to 95% halves origin egress. Storage at the edge is second, and it's why pull exists for the long tail rather than pushing everything everywhere. If I were optimizing spend I'd look at hit ratio first, then at whether tail content needs to be at edges at all versus only at parents.

"Would you build this or buy it?"

Buy, almost certainly. Building only pays when your traffic volume distorts provider pricing and your catalogue supports a very high hit ratio — Netflix gets to 95% because the library is bounded and demand is concentrated. Worth noting they built the data plane but ran the control plane on AWS: build where your cost curve is unusual, buy where it isn't. Even having built it, they keep public CDNs for overflow and failure.

Now do it live

The next section drills these as standalone probes.