Design Netflix

You're asked to design a subscription video streaming service. The catalog is a fixed set of professionally produced titles rather than user uploads, a subscriber opens the app and sees a personalized set of rows, and pressing play starts video in under a second at the best quality their connection supports. Playback position syncs across devices, and the service accounts for a large share of internet traffic in every country it operates in.

YouTube's difficulty is that content arrives continuously and unpredictably. Here the catalog is known weeks in advance, which sounds easier and changes the problem rather than removing it: when you know exactly what people will watch and roughly when, the design question becomes how much work you can do before anyone presses play.

Clarifying the requirements

• Is the catalog fixed? Yes. Titles are ingested by the business, not uploaded by users. Confirming this early is what separates this design from YouTube's.
• How fast must playback start? Under a second, which is the constraint that drives most of the delivery design.
• Is the personalized home page in scope? Usually yes at least in outline, since it's what the subscriber actually sees first.
• Do we support offline downloads? Common in the modern product, and it interacts with DRM in a way worth mentioning.
• How many concurrent streams per account? A product rule with a real enforcement design behind it, and a good smaller topic if time allows.

Assume: fixed catalog, sub-second start, personalized home page in scope, offline downloads supported.

Back-of-envelope numbers

• Subscribers: $300\text{M}$, with roughly $10\%$ streaming at peak, so $30\text{M concurrent streams}$
• Peak egress at an average $5\text{ Mbps}$: $30\text{M} \times 5\text{ Mbps} = 150\text{ Tbps}$
• Catalog size: $20\text{k titles} \times 1 \text{ hour avg} \times 50 \text{ encoded variants} \times 2\text{ GB/hour} \approx 2\text{ PB}$ of encoded content
• New content: $1\text{k hours/month}$ ingested, which is a scheduled pipeline rather than a firehose
• A popular new release: tens of millions of viewers within days, concentrated in the first evening

The contrast with YouTube is the point. Two petabytes is small enough to consider placing a meaningful fraction of the entire catalog at every edge location, which is an option that doesn't exist when the catalog grows by petabytes a day.

High-level architecture

Components

1. Offline encoding. Produces every variant weeks before release, with no latency pressure.
2. Encoded catalog. The authoritative copy of all renditions and manifests.
3. Pre-positioning. Copies content to edge appliances ahead of predicted demand.
4. ISP appliances. Servers physically inside internet providers' networks, holding the popular catalog.
5. Control plane. Authentication, entitlements, playback session setup. Small and stateless relative to the data plane.
6. Personalization. Builds the rows the subscriber sees.
7. Steering service. Picks the best appliance for this client right now.

Deep dive 1: encoding offline changes what's worth doing

Because encoding happens weeks ahead of release, it isn't on any critical path, which means you can spend far more compute per title than a service encoding on upload ever could, and get real quality and bandwidth wins for it.

Per-title encoding is the clearest example. Every title is encoded into a bitrate ladder, with one version per resolution and bitrate a player might request, and applying the same fixed ladder to every title wastes bits on simple content while starving complex content. An animated show with flat colour holds up at a far lower bitrate than a fast-moving action sequence, so analysing each title and choosing a ladder for it produces better quality at lower bitrate. Since bandwidth is the dominant cost at 150 Tbps, a double-digit percentage reduction is enormous.

Per-shot encoding takes it further, varying the ladder within a title, since a single film contains both a static dialogue scene and a chaotic chase.

Two more things the offline window buys:

• Multiple codecs. Encoding the same title in H.264, HEVC, and AV1 lets each device get the most efficient codec it can decode. Newer codecs cut bandwidth substantially, and the encoding cost is irrelevant when it's done once, ahead of time, for a title that will be streamed millions of times.
• Quality verification before release. Every rendition can be checked with a perceptual quality metric and re-encoded if it falls short. A service encoding on upload has no equivalent opportunity.

The general principle is worth stating: when content is known in advance, move every possible unit of work off the request path, because compute spent once is amortized across every future stream.

Deep dive 2: putting content inside ISP networks

A hundred and fifty terabits per second doesn't leave a datacenter, and even a conventional CDN means that traffic crossing transit links to reach subscribers. The design that answers this is to place servers inside the internet providers' own networks.

Netflix's Open Connect appliances are the real-world example: hardware installed in ISP facilities, holding a large portion of the catalog. A subscriber's stream then travels from a box inside their provider's network rather than across the public internet.

Everyone benefits, which is why ISPs agree to host them:

• The subscriber gets lower latency and fewer congestion-related quality drops.
• The ISP stops paying for transit on what is often the largest single share of its traffic.
• The service gets predictable delivery it doesn't have to buy per gigabyte.

Fill happens during off-peak hours. Appliances update overnight, when both the ISP's network and the origin are quiet, so the delivery of content costs nothing during the hours anyone is watching. This is only possible because the catalog is known ahead of time, since you cannot pre-position content that doesn't exist yet.

What to place is a prediction problem. Each appliance holds a subset chosen from regional viewing history, upcoming releases, and time of day. A new season everyone will watch on Friday night is pushed everywhere on Thursday. The long tail lives at regional caches, and a request for something not held locally falls back a tier rather than failing.

Deep dive 3: starting playback in under a second

Sub-second startup is a product requirement with several independent contributors, and the useful answer enumerates them rather than naming one.

• Prefetch the manifest before play is pressed. When a subscriber is browsing a title's detail page, the client can already have fetched the manifest and resolved which appliance to use, so pressing play begins with a segment request rather than three round trips.
• Start at a conservative rendition. A small first segment arrives fast, and adaptive bitrate steps up within seconds. Startup time affects abandonment far more than initial quality does.
• Use short segments at the start. Two-second opening segments and longer ones later gives fast startup without paying per-segment overhead for the whole stream.
• Keep the control plane off the byte path. Authentication and entitlement checks happen once at session setup; every segment afterward goes straight to the appliance. A control plane in the middle of playback would add latency to every segment and become a scaling problem in its own right.
• Resume where the subscriber left off. Playback position is small, frequently written state, best kept in a fast key-value store and written on a short interval rather than on every position change.

Deep dive 4: the personalized home page

The home page is what the subscriber sees before any video plays, and it's assembled rather than retrieved.

The structure is rows, each a themed set of titles, with both the rows and their contents personalized. That's two ranking problems, which rows to show and what goes in each, and the design consequence is that a home page is expensive to build.

Precompute it. Building each subscriber's page on request means running ranking at page-load latency for three hundred million people. Instead, a batch job computes pages ahead of time and stores them, and the request becomes a lookup. Freshness is traded for latency, which is the correct trade when yesterday's recommendations are almost as good as today's.

Layer a small amount of real-time on top. The precomputed page is adjusted at request time for things that must be current: continue watching, recently added, and anything the subscriber just interacted with. A precomputed base with a live overlay gets most of the personalization quality at a small fraction of the cost.

Artwork is personalized too, and it's a detail worth mentioning because it surprises people: the same title may be shown with different thumbnails to different subscribers based on what they respond to. Practically it means the image variants are part of the personalization payload, not a static property of the title.

Common pitfalls

• Encoding one universal bitrate ladder. Content complexity varies enormously, and bandwidth is the dominant cost.
• Treating the CDN as a generic third-party service. At this share of internet traffic, placement inside ISP networks is the design, not an optimization.
• Filling edge caches on demand. Pulling a new release during peak hours creates exactly the congestion the design exists to avoid.
• Putting the control plane in the segment path. It adds latency to every segment and becomes a bottleneck.
• Computing the home page on request. Ranking at page-load latency for the full subscriber base is not affordable.

Leveling the answer

Related lessons

Design YouTubeHard

Ingest and transcode continuous user uploads, then deliver them worldwide.

Design TikTokHard

Serve an endless personalized feed of short videos with near-instant playback.