Designing Netflix

We are designing a platform where users browse a content catalog, search for titles, and stream video — smoothly, on any device, on any network, anywhere in the world.

The experience looks simple: open the app, pick a movie, press play. Underneath that simplicity is one of the most bandwidth-intensive workloads in modern infrastructure — delivering gigabits per second of continuous video to very large numbers of concurrent viewers (an illustrative design target, not a published figure), across every continent, on networks that vary from gigabit fiber to weak mobile signal.

The core split: control vs data

The single most important observation about a video streaming platform is that it has two fundamentally different workloads. The control plane handles browsing, search, authentication, recommendations, and playback metadata — relatively small requests, latency-sensitive, but manageable volume. The data plane handles the actual video bytes — enormous, continuous, bandwidth-dominated. Treating these the same way is the most common architectural mistake in this problem space.

Functional requirements define what the system does. Non-functional requirements define how it must behave at scale and under failure — and for a streaming platform, the second list drives the entire architecture.

Functional

Browse content catalog. Search by title, genre, person. Start, pause, resume, and seek video. Stream across devices (TV, phone, browser). Maintain per-user watch state. Personalized recommendations and content discovery.

Non-functional

Start with the simplest thing that could work: one streaming API, one storage system, one region.

At small scale this is fine. The API accepts playback requests, fetches video from storage, streams it to the viewer. No CDN, no adaptive bitrate, no encoding pipeline. A few hundred users can be served this way.

Where this breaks

Video streaming is bandwidth-dominated. Unlike a typical API request that returns kilobytes, a 1080p video stream requires 8+ Mbps continuously per viewer. A single server exhausts its network capacity very quickly. Worse, users in other countries experience high latency because every byte travels from one data center, potentially across oceans.

The first major architectural decision: the control plane and data plane must be separate infrastructure.

The control plane serves browsing, search, auth, recommendations, and playback manifest URLs. These are small, fast requests — a few kilobytes each. The data plane serves video bytes — gigabits per second, continuously. Mixing them on the same servers means a video stream spike can starve catalog browsing, and a recommendation computation can delay playback. (Personalization is a substantial system on its own — see the full Recommendation System deep dive.)

Control plane: a horizontally-scaled API cluster backed by a catalog database, recommendation service, and user-state store. Each service scales independently based on its own load patterns.

Data plane: object storage (the origin) served through CDN. The control plane never touches video bytes after returning a signed manifest URL to the player.

A raw uploaded video cannot be streamed directly. It must be transcoded into multiple representations, then segmented for adaptive delivery.

A single master video file is encoded into multiple resolution/bitrate combinations. Example ladder (illustrative, not Netflix's actual encodes): 4K at 15+ Mbps, 1080p at 8 Mbps, 720p at 5 Mbps, 480p at 2 Mbps, 360p at 0.5 Mbps. Each rendition is then split into 2-4 second segments. A manifest file lists every rendition, every segment URL, and each segment's duration. In practice, the exact rendition ladder is tuned per title rather than fixed — see Per-Title Encoding for how.

Why async encoding

Transcoding is CPU-intensive and can take minutes to hours per title. It runs asynchronously after the upload completes. A queue receives the upload notification and fans it out to encoding workers — one per target rendition, running in parallel. When encoding completes, all renditions and segments are written to object storage.

The CDN is not an optimization — it is the primary delivery mechanism. Without it, global streaming at this scale is physically impossible.

A CDN has edge nodes in hundreds of cities worldwide. Video segments are cached at these edges. A viewer in Tokyo fetches segments from a CDN node in Tokyo — single-digit millisecond latency. Without CDN, the same viewer fetches from a US data center — roughly 150ms round-trip, on every 2-4 second segment request.

Cache miss and cache hit

On the first request for a segment at a given edge, the edge fetches it from origin storage and caches it. Every subsequent request for that segment at that edge is a cache hit — served instantly from local storage, no origin involved. For popular content, the cache hit rate approaches 99%+. The origin serves only the initial cache-fill traffic.

At Netflix's actual scale, the CDN described above is largely Netflix's own purpose-built network, Open Connect, rather than a third-party CDN — see the Open Connect deep dive for why that distinction matters.

Adaptive Bitrate (ABR) streaming lets the player continuously match quality to available bandwidth, trading resolution for continuity.

At every segment boundary, the player measures how quickly the last segment downloaded versus how quickly it is being consumed. If the download rate exceeds playback rate, it can request a higher quality rendition. If download rate falls behind, it switches to a lower quality rendition to avoid buffering.

The trade-off

ABR accepts visible quality reduction to avoid playback interruption. A buffering spinner is always worse than a quality drop. The system is tuned to keep the buffer ahead by several seconds — enough to absorb brief network fluctuations without user-visible impact.

Global delivery is a direct consequence of physics: signal propagation in fiber alone adds roughly 30 ms one way across the Atlantic (about 70–90 ms round trip once routing is included). CDN edges eliminate that delay for video bytes.

Each geographic region has CDN edge nodes close to users. DNS-based routing or anycast directs each user's requests to their nearest edge. In the target state the control plane is also multi-region — authentication and catalog queries are served from regional API clusters, not a single global data center. A first version can start with one primary control-plane region plus a warm standby and regionalize later (see Core Trade-offs).

Video bytes almost never cross ocean cables after initial CDN seeding. Content is cached at regional edges after first request and served locally to all subsequent viewers in that region.

A major new release launches. Tens of millions of users press play in the same hour. What happens?

Without CDN: origin storage would receive every segment request itself — on the order of millions per second under the illustrative assumption in the failure scenarios (50M concurrent viewers, one 4-second segment each). No origin can sustain that load.

With CDN: the first viewer at each edge triggers a cache fill, and every viewer after that is a cache hit — so origin sees only a small fraction of total traffic even during the largest launches.

At global scale, failures are not exceptional — they are routine. The architecture must handle them without user-visible impact.

CDN edge failure

A single CDN node goes down. DNS health checks detect it within seconds, traffic reroutes to the next nearest edge, and streams continue at slightly higher latency with no data loss.

Regional failure

An entire region becomes unavailable. The multi-region control plane reroutes affected users to alternate regions, and CDN edges and origin storage elsewhere absorb the redirected load.

Network degradation

Widespread congestion reduces available bandwidth for many users at once. Adaptive streaming reduces quality across the board rather than buffering, and recovers automatically as congestion clears.

These are just the headline scenarios — see the full Failure & Scale Scenarios page for deeper walkthroughs of each, plus additional scenarios not covered here.

Every architectural decision in a streaming platform involves a trade-off. Being explicit about them is the mark of a strong design.

Four trade-offs recur throughout this design: origin vs CDN (origin stays authoritative, CDN handles delivery at scale), quality vs bandwidth (adaptive streaming finds the best fit for current network conditions), pre-encoding vs on-demand transcoding (pre-encoding wins at streaming scale despite the storage cost), and centralized vs multi-region control plane (centralized is simpler; multi-region is required for global availability).

Each of these is examined in full, including two additional trade-offs around recommendations and watch-state consistency, on the Trade-offs & Decisions page.

The architecture emerges directly from the requirements. Every component is justified by a real bottleneck.

Upload path: Studio upload → encoding queue → parallel transcoding workers → multiple renditions + segments → object storage.

Playback path: User opens app → control plane (auth + catalog + manifest URL) → player fetches manifest from CDN → player fetches segments from CDN edge → CDN fills from origin on cache miss → adaptive bitrate switches quality as network changes.