One movie, 190 countries, zero buffering: how Netflix answers the interview

The prompt shows up in system-design interviews in almost exactly this form:

Netflix has 270 million subscribers. 45% watch at the same time on Friday night — that's ~120 million streams simultaneously, each needing 4–15 Mbps. One movie, 190 countries, zero buffering. How is that possible?

The trap is that it sounds like a streaming problem, so people start drawing video servers. It is really a traffic-placement problem. Once you do the arithmetic, the answer writes itself: you cannot serve this from a data centre, so the only move left is to have the bytes already sitting next to the viewer before they press play. Everything Netflix built — Open Connect, predictive fill, adaptive bitrate, the AWS split — falls out of that one constraint.

Step 1: do the napkin math

Never accept the interviewer's numbers as scenery. They are the whole question. Multiply them out.

Napkin math: 120M concurrent streams × the bitrate per stream = total egress the system must sustain at once.

• Floor (4 Mbps): 120,000,000 × 4 = 480 Tbps
• Ceiling (15 Mbps): 120,000,000 × 15 = 1,800 Tbps ≈ 1.8 Pbps
• Realistic mix (_{8 Mbps): ≈ **960 Tbps ≈} 1 petabit per second**

So the system has to push on the order of a petabit per second, continuously, during peak. Hold that number — it is the fact that kills every naive design.

For scale: one of the largest internet exchange points on the planet, DE-CIX Frankfurt, peaks in the high tens of Tbps.² A petabit per second is roughly 50–100× an entire major exchange. There is no building, no fibre bundle, no cloud region with that egress.

The other number that matters is storage read pattern, not size. A single popular title, encoded into every rendition Netflix ships (many codecs × resolutions × bitrates), is a few hundred GB. Trivial to store once. The problem was never storing the movie — it is reading it 120 million times from places close enough that no packet crosses an ocean under load.

Step 2: see why the obvious designs die

Walk the interviewer through the failures on purpose. It shows you understand the constraint, and it motivates the real answer.

Every row fails at the same place: the bytes are too far from the viewer, and there are too many viewers. Distance is the enemy — each hop adds latency and each transit link is a place congestion can start. The winning idea is to delete the distance.

Step 3: move the bytes to the edge — Open Connect

Netflix's answer is its own CDN, Open Connect. Instead of streaming from a central origin, Netflix ships purpose-built cache servers — Open Connect Appliances (OCAs) — and places them inside the network, either directly in ISP data centres or at internet exchange points.³ Each is a dense box of storage and NICs whose only job is to serve video chunks over HTTP at line rate.

The consequence: a viewer's stream terminates at a box that is often one network hop away, inside their own ISP. The bytes never touch the public backbone, never cross an ocean at play time, and never hit a Netflix data centre. The ~1 Pbps is not served from one place — it is the sum of thousands of OCAs each serving a manageable slice to the users nearest them.

flowchart TB
    subgraph edge["Open Connect — the data plane"]
        direction LR
        O1["OCA<br/>inside ISP A"]
        O2["OCA<br/>at IX point"]
        O3["OCA<br/>inside ISP C"]
    end
    V1["Viewers on ISP A"] --> O1
    V2["Viewers near IX"] --> O2
    V3["Viewers on ISP C"] --> O3
    origin["Netflix origin /<br/>fill source"] -. off-peak fill .-> O1
    origin -. off-peak fill .-> O2
    origin -. off-peak fill .-> O3

That dashed line is the trick that makes it affordable, and it deserves its own step.

Step 4: fill the caches before anyone watches — predictive fill

Here is the part people miss. If an OCA fetched the movie from origin the moment a viewer asked, you would have moved the bandwidth wall by one hop, not removed it — the origin still has to serve everything once.

Netflix instead does proactive, predictive fill. During off-peak hours (the small morning window in each region), OCAs pull the content they are predicted to need, guided by what is popular in that locale and by the recommendation and viewing data.³ By the time Friday night arrives, the movie is already sitting on the OCA inside your ISP. Peak traffic reads from local disk; it never becomes origin traffic at all.

So the same title being watched by millions is not fetched millions of times across the backbone. It is fetched once per OCA, hours early, when the network is quiet, then read locally millions of times. That is how "one movie, 120 million streams" stops being a contradiction.

title: A play request, hit vs miss
packets: on

scenario "Warm cache (the normal case)"
> The OCA inside your ISP was filled hours ago, off-peak. Peak traffic is local.
Client [your TV app] --> Steering (which OCA?) {secure}
Steering [runs on AWS] --> Client (ranked OCA list) {allowed}
Client --> OCA (fetch chunks over HTTP) {secure}
OCA [inside your ISP] --> Client (video, ~1 hop) {allowed}
> No backbone, no origin, no ocean crossing.

scenario "Cold miss (rare)"
> Content not yet on the nearest OCA — fall back up the hierarchy, once.
Client --> Steering (which OCA?) {secure}
Steering --> Client (next-best OCA) {neutral}
Client --> OCA (request) {neutral}
OCA --> Origin (fill this title) {neutral}
Origin --> OCA (content) {neutral}
OCA --> Client (video) {allowed}
> The miss fills the cache, so every later viewer takes the warm path above.

Step 5: absorb the 4–15 Mbps spread — adaptive bitrate

Why is the per-stream number a range, not a fixed value? Because the client, not the server, decides how much bandwidth it uses — moment to moment. That is adaptive bitrate streaming (ABR), delivered over HLS/DASH.

Netflix encodes each title into a ladder of renditions ahead of time. The video is cut into small chunks (a few seconds each), and the player measures throughput and buffer health and picks the highest rendition it can sustain for the next chunk. Network dips → step down a rung, no stall. Network recovers → step back up.

Two refinements make the ladder cheaper and sharper than a fixed one:

• Per-title encoding — a simple cartoon and a grainy action film do not need the same bitrate for the same quality, so the ladder is computed per title rather than applied uniformly.⁴
• Per-shot / newer codecs — bitrate is tuned per scene, and efficient codecs (AV1, HEVC) hit the same quality for fewer bits, which directly shrinks the ~1 Pbps.

ABR is what turns "zero buffering" from a promise into a fallback: the system does not guarantee 4K to everyone — it guarantees the best rung your link can hold right now, and degrades a notch instead of stalling. 4–15 Mbps is the ladder, not a target.

Step 6: split the plane — AWS vs Open Connect

The last piece is knowing what doesn't run on the CDN. Netflix runs two systems with a clean seam between them:⁵

• Control plane — on AWS. Sign-in, the app UI, search, the recommendation engine, billing, encoding pipelines, A/B tests, the API that answers "play this title." All the logic. None of the video bytes.
• Data plane — on Open Connect. Only the video chunks, served from OCAs at the edge.

When you press play, the client asks an AWS service, and a steering component returns a ranked list of OCAs for that client — chosen by network proximity, current OCA health and load, and which boxes actually hold that title. The client then pulls chunks straight from the best OCA over HTTP. AWS handled the decision; Open Connect handles the delivery.

sequenceDiagram
    participant C as Client app
    participant A as AWS control plane
    participant S as Steering service
    participant O as OCA (edge)
    C->>A: authenticate, browse, pick a title
    A-->>C: metadata + manifest
    C->>S: where do I stream this from?
    S-->>C: ranked list of OCAs
    C->>O: GET chunk 1, 2, 3 … (HTTP)
    O-->>C: video bytes (~1 hop away)
    Note over C,O: player runs ABR, steps rungs per chunk

This separation is why the two halves scale independently. Control-plane traffic is small JSON. Data-plane traffic is the petabit. Keeping them apart means the expensive part (bytes) lives where bytes are cheap (the ISP edge), and the smart part (decisions) lives where compute is elastic (the cloud).

The one-paragraph answer

If the interviewer wants it in thirty seconds: You never serve 120 million streams from a data centre — the math is ~1 Pbps, which no facility can egress. Netflix runs its own CDN, Open Connect, placing cache appliances inside ISPs and exchanges. Content is predictively filled to those caches off-peak, so peak reads are local — one hop from the viewer, off-backbone. Adaptive bitrate lets each client pick a rung between 4 and 15 Mbps and degrade instead of stall. AWS runs the control plane (auth, recommendations, steering); Open Connect runs the data plane (the bytes). Distance is the enemy, so the design deletes the distance.

What the interviewer is really testing

The Netflix numbers are a prompt, but the skill is general. The reusable moves:

1. Multiply the numbers first. The petabit is hiding in the prompt; find it before you design anything.
2. Name the binding constraint. Here it is egress bandwidth and distance, not storage or compute.
3. Push work to the edge and earlier in time. A cache is just "closer in space"; a predictive cache is also "earlier in time." Both remove load from the hot path.
4. Split control from data. Let the smart, small traffic and the dumb, huge traffic scale on different infrastructure.

Any CDN-shaped question — a viral video, a global game launch, a software update to a billion devices — answers to the same four. Netflix is just the cleanest place to see them.