Design Netflix

Problem statement

Design a service that streams a curated catalog of movies and shows to a global audience, smoothly, on any device and any connection. A studio delivers a high-quality master file for each title; the service transcodes it, stores it, and plays it back on demand. Viewers expect playback to start within a second or two, to stay smooth as bandwidth changes, to seek anywhere in a title, and to resume on a television where they left off on a phone.

The scope here is ingest and delivery: taking a master and making it watchable, then serving it at scale. Home-page ranking and search are a separate recommendation problem; billing is a separate payment problem; the internals of digital rights management (DRM) are named where they touch delivery and otherwise deferred.

Clarifying questions

Each question below fixes an assumption the rest of the design leans on.

• Video-on-demand or live? Video-on-demand (VOD) serves pre-recorded files transcoded ahead of time. Live transcodes in real time under tight latency and is a different system, covered as a variant. Assume VOD.
• User-generated or a curated catalog? Curated and licensed. Studios deliver a high-quality master (also called a mezzanine file), so there is no upload firehose, transcoding runs offline and unhurried, and — the load-bearing point — which titles will be popular is predictable in advance.
• Global? Yes, and it is central. Viewers are worldwide, so per-region storage and caches placed close to users are first-order concerns from the start.
• Recommendations and search in scope? Deferred as a separate ranking-and-retrieval problem. Assume a catalog browse exists; focus on ingest and delivery.
• Billing, profiles, DRM? Billing is the payment-system problem. DRM (encrypting segments, issuing license keys) is real and named where it interacts with caching, its internals deferred. Profiles are a light per-user layer.
• What sizes the system? Peak concurrent-stream egress bandwidth. The catalog is large but bounded; both the cost and the engineering live in moving bytes to viewers.

What makes this problem distinctive

A basic answer stores each title and streams the bytes back from a server. Two forces break that, and the second determines the delivery architecture.

The first is that one file cannot play everywhere. A phone on a weak cellular signal and a television on fiber cannot share a single encoding, so each title becomes an encoding ladder — the same video at many resolutions and bitrates — sliced into short segments a player switches between second by second. This part Netflix shares with any video platform.

The second force dominates: delivery economics. Streaming to tens of millions of concurrent viewers is an egress-bandwidth problem measured in terabits per second, and a single origin cannot serve that, so almost every byte must come from a cache near the viewer. What sets this problem apart from a general video platform is a lever it can use to reach that hit rate: the catalog is finite, and which titles will be popular is predictable in advance. A platform flooded with unpredictable user uploads has no such foresight; a licensed catalog does. How the design turns that predictability into a near-complete hit rate is worked out in the high-level design.

Ingress and egress. Ingress is data entering the system — here, the studio masters, a modest trickle. Egress is data leaving it — the bytes streamed to viewers. For a streaming service egress dwarfs ingress by orders of magnitude, because a small catalog is watched an enormous number of times. Egress is the quantity that shapes the design.

The tension the whole design resolves: every byte served from the origin costs origin bandwidth the system cannot afford, yet a byte can only be served from the edge if it is already there. The diagram shows the forces, not the answer.

Key idea. Netflix's defining trait is delivery economics, and its defining lever is a predictable catalog that can be pushed to the edge before demand arrives.

Key concepts

This section covers the concepts needed to solve this problem — prerequisites for the design work that follows. These are the streaming fundamentals the later sections assume as known vocabulary; they are reviewed here directly rather than derived from a failure.

Playback is a client-driven loop. The player downloads a small manifest listing the available qualities and the URLs of the segments that make up the video, then fetches segments a few seconds at a time into a buffer — a short queue of already-downloaded video waiting to play. It plays from the buffer while downloading ahead, so a brief network dip drains the buffer instead of stalling, and at each segment boundary the player can switch quality. The widget shows the loop.

Rendition

A rendition is the same title encoded at one resolution and bitrate — a single rung of the ladder. A lower bitrate means a smaller file and lower quality; a higher bitrate means better quality and more bytes to move. Because every byte moved is an egress cost multiplied across millions of streams, the bitrate of each rung is not a cosmetic choice — it is the cost knob.

Reading bitrate. Bitrate is measured in megabits per second (Mbps) — the rate at which the stream delivers data. Eight bits make a byte, so 5 Mbps is about 0.6 MB per second. To play without stalling, the connection must sustain at least the rendition's bitrate.

Codec

A codec compresses each rendition. It stores one full keyframe and then only the differences between frames, which is where the compression comes from. A more efficient codec reaches the same quality at a lower bitrate — and lower bitrate at equal quality is a permanent egress saving, so codec choice trades encoding CPU for delivery cost.

Encoding ladder

The encoding ladder is the set of renditions produced from one master — for example 240p through 4K, one rung per device and network class. The same title exists at every rung, so the player can drop to a lower quality when the connection can sustain one of the available rungs.

Segments and the manifest

A rendition is not fetched as one file. Each is divided into short segments of a few seconds — the unit that is requested and cached. A manifest lists the renditions and, per rendition, the ordered segment URLs. Two manifest formats dominate: HLS (HTTP Live Streaming, Apple's .m3u8) and DASH (Dynamic Adaptive Streaming over HTTP, the open .mpd standard); both follow the same manifest-plus-segments model. The player reads the manifest and fetches segments in order.

Adaptive bitrate (ABR)

The player, not the server, selects the quality. It measures available bandwidth and buffer level and, at each segment boundary, requests the next segment at the highest rung it can sustain — stepping down when the signal weakens and back up when it recovers. The server serves plain cacheable segments and holds no per-viewer state, which is what lets a cache absorb nearly all the traffic.

Rebuffering

If the buffer empties, playback stalls until new data arrives — a rebuffer, the spinning-wheel pause. It happens when the network cannot deliver the chosen quality fast enough. Preventing it is why ABR exists: in the widget, a fixed high-quality stream stalls during a bandwidth dip, while adaptive mode drops to a lower rung the network can sustain and keeps playing. Viewers tolerate a brief quality drop far better than a stall.

Key idea. Playback is a client-driven loop — read the manifest, fill a buffer, switch rendition per segment — and every rung's bitrate is an egress cost.