Design Netflix

The big idea

What does streaming take?

One title streamed to hundreds of millions of people, on every device and connection speed, starting in under two seconds and never buffering. That’s petabytes of video moving constantly — no single data center could push that much traffic to the world.

The trick: don’t send video from the middle. Pre-encode each title into many quality levels, push copies to caches near every viewer, and let the player pick the bitrate its connection can handle, segment by segment. The control path is tiny; the data path lives at the edge.

How to read this: We add one piece at a time — but you make each design call before the answer is revealed. The diagram only grows when you commit. Hit Begin.

Step 1 · Press play

The play path

Tapping play has to do two very different things fast: confirm you’re allowed to watch this title here, and figure out where to get the bytes. Mixing authorization with byte delivery would make both slow.

Design decision: Press play. Two jobs: check the viewer is allowed, and deliver gigabytes of video. How do you split it?

The call: An API authorizes and returns a manifest; the player streams from a CDN. — Control plane and data plane split cleanly — the API makes small smart decisions, the CDN moves the bytes. Each scales on its own terms.

The Playback API checks the Catalog (subscription, region, licensing), then a Manifest Service returns a descriptor pointing the player at the nearest CDN edge. The player then streams chunks straight from the edge — control and data are cleanly split.

Control plane vs data plane: The API handles the small, smart decisions (auth, which manifest); the CDN handles the massive, dumb byte-pushing. Keeping them separate lets each scale on its own terms.

Step 2 · Where the bytes live

Origin & edge

Every viewer streaming from one central store would saturate it instantly and add cross-country latency to every chunk. Yet you still need one durable, authoritative copy of every title.

Design decision: Hundreds of millions of viewers need the same files. Where do the bytes live?

The call: Durable origin storage, plus edge caches that pull on a miss. — Origin holds everything once; edges cache what their viewers actually watch. Immutable segments mean the cache never goes stale.

Keep masters and all encodings in Origin Storage (cheap, durable blob storage), but serve viewers from CDN edges. On a cache miss the edge pulls a segment from origin once, then serves it to everyone nearby. Video segments are immutable, so they cache forever.

Cache the immutable: A video chunk never changes, which makes it the perfect cache target — long TTLs, no invalidation. Origin is the source of truth; the edge is where ~95%+ of bytes are actually served.

Step 3 · One stream, every connection

Adaptive bitrate

A phone on 3G and a TV on fiber can’t use the same file. A fixed quality either buffers constantly for the slow viewer or looks terrible for the fast one — and connections change mid-show.

Design decision: A phone on flaky 3G and a TV on fiber both press play on the same film. What do you ship them?

The call: Encode many qualities; the player switches between them per segment. — The intelligence lives in the client. The server just offers a ladder; the player climbs and drops it as its own throughput changes.

Encode each title as an ABR ladder: the same content at many resolutions/bitrates, each sliced into short segments. The manifest lists them all; the player measures throughput and switches levels per segment, climbing in quality or dropping to avoid a stall.

The player decides: Intelligence lives in the client. The server just offers options (the ladder); the player picks the best one it can sustain right now, smoothing over network bumps invisibly.

Step 4 · Make the ladder

The transcoding pipeline

Studios deliver one giant, pristine master. Devices need dozens of encodings (codecs, resolutions, bitrates) of it — and re-encoding a two-hour film serially would take ages per title.

Design decision: The studio hands you one pristine 2-hour master. Encoding it into ~10 quality rungs serially would take days. What now?

The call: Chop the master into chunks; encode every chunk × rung in parallel across a fleet. — Segments are independent, so a movie becomes ~18,000 small jobs. Throw workers at it and days become minutes-to-hours.

A Transcode Pipeline splits the master into chunks and encodes each chunk at every rung of the ladder in parallel across a worker fleet, then writes the renditions to origin. Chunking turns a slow serial job into a massively parallel one.

Parallelize by chunk: Because segments are independent, transcoding scales horizontally — throw more workers at it to encode a movie in minutes. This offline pipeline is what makes the cheap, fast play path possible.

Step 5 · Closer than the cloud

Open Connect at the ISP

Even regional CDNs sit a few network hops away, and at streaming’s scale the bandwidth between ISPs and the CDN becomes a real cost and bottleneck — especially when everyone watches the new release at once.

Design decision: A new season drops Friday 8pm and a whole country presses play at once. How do you survive it?

The call: Pre-position the likely hits inside ISPs’ own networks, overnight. — Tomorrow’s demand is predictable, so fill caches sitting inside the ISP during off-peak hours. At 8pm it’s just a local file read, next door.

Push popular content even closer: place cache appliances inside ISPs’ networks (Netflix calls this Open Connect) and pre-position likely-popular titles overnight, before demand hits. Most streams are then served from within the viewer’s own ISP.

Predict and pre-fill: Because tomorrow’s hits are predictable, you can fill edge caches during off-peak hours. Delivery stops being a live fetch and becomes reading a file that’s already next door.

Step 6 · What to watch next

Recommendations

With tens of thousands of titles, a viewer who has to search for something often just leaves. Discovery, not playback, is what keeps people subscribed.

Design decision: 200M+ members, tens of thousands of titles. Where do you compute each person’s homepage ranking?

The call: Mostly offline and cached, with a light personalization pass at request time. — Precompute candidates and rankings in batch, then cheaply re-rank with fresh context (time of day, device) on load. The same candidate-then-rank pattern as any feed.

A Recommendations system ranks titles per user from viewing history and similarity, building the personalized rows on the home screen. It’s computed largely offline and cached, then lightly personalized at request time — the same candidate-then-rank pattern as a feed.

Discovery is the product: The catalog is huge; attention is tiny. Surfacing the right title is as much an engineering problem as streaming it, and it’s fed by the playback events we add next.

Step 7 · Measure everything

Playback events & QoE

You can’t see what users see. Is a region buffering? Did a CDN node degrade? Which titles are actually watched to the end? Without telemetry you’re flying blind on quality and on billing.

Design decision: A CDN node in São Paulo starts silently degrading at 9pm. How do you find out?

The call: Stream telemetry from every player — startup time, rebuffers, bitrate switches. — The player sees the truth. Aggregate QoE events per region and edge in near-real-time, and a degrading node lights up in minutes — then you route around it.

The player streams Playback Events — start time, rebuffers, bitrate switches, watch progress — onto an event pipeline. Those feed real-time QoE monitoring (route around a bad edge), view counting, and the recommendation models, closing the loop.

Close the loop: Quality of Experience is the north-star metric. Measuring real playback lets you shift traffic off failing caches, prove value, and improve recommendations — all from the same event stream.

You did it

You just designed Netflix.

• A play path that splits authorization (API) from byte delivery (CDN).
• Durable origin storage with immutable segments cached at the edge.
• An adaptive-bitrate ladder the player switches between per segment.
• A parallel, chunked transcoding pipeline that builds the ladder offline.
• Open Connect caches inside ISPs, pre-filled with predicted-popular titles.
• A recommendation system that drives discovery across a huge catalog.
• Playback/QoE events that monitor quality, count views and feed recs.