Design Netflix

Netflix and YouTube look alike and are not. YouTube ingests

500 hours a minute of unpredictable user content; Netflix has a **finite, curated catalogue

known in advance**. That single difference changes the entire design — you can afford to encode extremely carefully once, and you can push content to the edge before anyone asks for it.

Requirements

Functional

• Browse a catalogue, search, get personalised recommendations.
• Stream video with adaptive quality; resume where you left off across devices.
• Multiple profiles per account; downloads for offline viewing.

Non-functional

• Playback starts in ~2 seconds and never buffers.
• Available globally, at peak evening concurrency.
• Enormous bandwidth, concentrated in regional prime-time windows.

250M subscribers, ~50M concurrent at peak
Average bitrate 5 Mbps → 250 Tbps aggregate at peak
Catalogue: ~50K titles, but each stored in dozens of encodings

Encoding: do it once, do it well

Because the catalogue is finite and known, every title is encoded ahead of time into a matrix of renditions — resolution × bitrate × codec × audio track × subtitle language. A single film becomes over a hundred files.

The refinement worth naming is per-title (and per-shot) encoding: an animated title with flat colour needs far less bitrate than a dark, grainy action film for the same perceived quality. Choosing the bitrate ladder per title rather than using one global ladder cuts delivered bytes substantially — and bandwidth is the dominant cost, so that is a first-order optimisation, not a micro-optimisation.

Open Connect: the CDN is the system

Netflix does not primarily rent CDN capacity; it ships hardware. Open Connect Appliances are servers placed inside ISP networks, filled overnight with the content that region is predicted to want.

Off-peak: push predicted-popular titles to appliances inside each ISP
Peak:     the stream is served from inside the viewer's own ISP

Two consequences to state: traffic never crosses the public internet backbone at peak, which is why streaming is smooth in the evening; and the ISP saves transit costs, which is why they host the hardware. Prediction is what makes it work — a title nobody predicted falls back to a regional origin, which is slower and more expensive.

This is the answer to "how is this different from YouTube": a finite catalogue makes proactive placement possible; user-generated content does not.

Playback

1. Client requests a playback manifest for a title
2. Auth: is this account entitled? DRM licence issued
3. Steering service returns the best CDN endpoints for this client
4. Client fetches segments, adapting bitrate to measured bandwidth
5. Client reports playback position periodically

Adaptive bitrate over HLS/DASH, as in YouTube. DRM (Widevine, FairPlay, PlayReady) means segments are encrypted and a licence server issues per-session keys — a licensing requirement that constrains caching, since the encrypted bytes are cacheable but the keys are not.

Resume position is a high-frequency, low-value write: a heartbeat every few seconds per

concurrent stream. Write it to a fast key-value store, batch it, and accept that losing a few seconds of progress on a crash is fine. Do not put it in the transactional database.

Recommendations

The catalogue is small enough that ranking, not retrieval, is the problem. The pipeline:

Offline:  train models on viewing history, ratings, completion rates
          → precompute candidate sets and row orderings per profile
Online:   serve the precomputed homepage, lightly re-ranked for context
          (time of day, device, what was just watched)

Precomputation matters because the homepage is the first screen of every session — it must render immediately, and running a heavy model per request would not. Note also that recommendations are per profile, not per account, which is the detail that makes the data model interesting.

Artwork selection is personalised too: the same title shows a different thumbnail depending on what the model thinks appeals to you, chosen by bandit algorithms.

Catalogue and metadata

titles      title_id, name, description, genres, cast, rating, licences
availability title_id, region, start_date, end_date
profiles    profile_id, account_id, preferences, maturity_level
watch_state profile_id, title_id, position, updated_at

Regional availability is a first-class concern — licensing means a title exists in one

country and not another, so every catalogue query is filtered by region, and the answer changes on a licence expiry date.

Follow-ups to expect

• Downloads — encrypted files with an offline DRM licence and an expiry.
• Concurrent stream limits — a session registry per account, enforced at playback start.
• Live events — the opposite of the pre-positioned model: everyone watches the same

bytes at once, so it needs the low-latency streaming approach instead.

• A/B testing — Netflix tests aggressively; the design needs per-user variant assignment

threaded through the homepage service.

• Chaos engineering — deliberately killing instances in production to prove resilience,

which is a Netflix-specific answer worth citing.

• Cold start — a new profile with no history; ask for a few liked titles up front.

Track this problem on the System Design sheet.