System Design Arena

System Design: Netflix

Deliver premium video content globally with ABR streaming, personalization, and studio workflows.

Functional RequirementsNon-Functional RequirementsAPI Endpoints

Case Study

Video Streaming (Netflix)

Same conversation, diagrams, and wrap-up you expectโ€”now framed with clearer scaffolding and iconography.

Prompt

Design Netflix. Ingest studio assets, encode, distribute via Open Connect, personalize home screen, provide downloads, handle telemetry and billing.

Interview snapshot

  • โ€ข Topic: Video Streaming (Netflix)
  • โ€ข Expected depth: 45 - 60 minutes
  • โ€ข Focus areas: APIs, scale estimation, resilient architecture
  • โ€ข Wrap-up: risk, monitoring, disaster recovery

Key takeaways

  • โ€ข Content ingest with localization, subtitles, DRM.
  • โ€ข Playback start < 1.5 s.
  • โ€ข GET /api/home - personalized home screen.

๐ŸŽ™๏ธ Interview mode

Practice this like a real interview

Don't read the answer first. Work the framework against the bare prompt, then compare against what the interviewer expected at each step.

๐ŸŽฏ Start guided practice (free)

Scorecard

What the interviewer is evaluating

Requirements7/10
Scale estimation9/10
API design5/10
Architecture9/10
Trade-offs8/10
Failure handling8/10

Staff-level signal

Does the candidate know the traffic is so asymmetric that the answer is "build your own CDN" (Open Connect) โ€” and can they defend pre-positioning content by prediction?

๐Ÿง  Staff engineer judgment

The catalog is ~thousands of titles โ€” tiny. Do not design content storage like user-generated video; design distribution and prediction instead.

Calibration

The common (bad) answer

App โ†’ API โ†’ Streaming service โ†’ S3 + CloudFront

โŒ Why this scores poorly: At Netflix scale, third-party CDN economics collapse โ€” streaming is ~15% of downstream internet traffic. The interesting design is edge appliances inside ISPs and nightly pre-positioning, none of which this answer touches.

โœ“ What a strong answer adds

  • Split control plane (browse, auth, play decisions โ€” cloud) from data plane (video bytes โ€” edge).
  • Edge appliances in ISP racks, filled nightly with predicted-popular titles.
  • Playback steering: client gets ranked edge URLs, fails over itself.
  • Per-title encoding ladders โ€” bitrate tuned to content complexity saves double-digit bandwidth.
  • Resilience culture: assume any microservice can vanish (chaos testing) without stopping playback.

Build it up

Step-by-Step Walkthrough

Netflix inverts YouTube's problem: a tiny curated catalog watched by tens of millions at once. That inversion โ€” few titles, colossal concurrency โ€” is why the answer is pre-positioning bytes inside ISPs, not just renting a CDN.

1

Naive: stream the catalog from cloud origin

Studio masters land in object storage; a playback API returns a URL; clients stream from cloud regions. The catalog is small โ€” on the order of ~10K titles โ€” so storage is trivial and this works for a pilot market.

Concurrency kills it: ~30M concurrent viewers at ~5 Mbps is on the order of ~150 Tbps of egress. At cloud bandwidth prices that is ruinous, and physics is worse โ€” prime-time traffic crossing the public internet backbone means buffering exactly when everyone is watching. The bytes have to start closer to the viewer.

2

The encoding factory: one master, dozens of renditions

Before distribution, every title runs through an encoding pipeline: multiple codecs (AVC, HEVC, AV1) times a per-title bitrate ladder โ€” analyze each title's complexity and pick encode points, because a flat cartoon needs far fewer bits than an action film at the same quality. Add localization: subtitle tracks and audio dubs per region.

Every rendition is then packaged under DRM (Widevine, FairPlay, PlayReady for different device families). Tens of renditions per title pushes the encoded catalog into the tens of PB โ€” still small enough that the entire popular catalog can be replicated to the edge, which is the insight the next step cashes in.

3

Open Connect: put the CDN inside the ISP

Instead of renting a CDN, ship Open Connect appliances โ€” storage-dense caches โ€” into ISP data centers and peering points. During off-peak hours they pre-fill with what tomorrow's viewers will likely watch (popularity is predictable for a curated catalog). At prime time, most streams never leave the viewer's own ISP.

Playback becomes a control-plane conversation: GET /api/playback/{id}/manifest returns the ABR ladder, steering to the healthiest nearby appliance, plus DRM license info; the client fetches the license and streams segments locally, adapting bitrate per segment. This is how ~150 Tbps stops being your egress bill โ€” the data plane lives in ISPs.

?The question behind Open Connect

Why can Netflix pre-position content when YouTube cannot? Catalog size and predictability: ~10K titles with forecastable demand fit on an appliance; 500K daily uploads with long-tail demand do not. Naming that contrast shows you understand both systems.

4

The home screen is a model, not a query

With distribution solved, retention is the game. GET /api/home is assembled by a personalization service: ML ranks rows, orders titles within rows, and even picks which artwork variant each profile sees. Features come from viewing history โ€” ~200M profiles at ~2 KB is only ~400 GB in a feature store.

The cultural machinery matters as much as the model: everything ships behind A/B experiments, and interviewers love hearing that artwork selection is itself a bandit problem. Continue-watching state syncs via POST /api/profiles/{id}/resume so a pause on the TV resumes on the phone.

5

QoE telemetry, billing, and the guardrails

Clients report quality-of-experience continuously โ€” startup time, rebuffer events, bitrate achieved โ€” billions of events/day through Kafka into stream processing and the analytics lake. QoE dashboards sliced by ISP, device, and title are how you detect that one appliance, one ISP, or one bad encode is degrading prime time, and they gate the sub-1.5 s playback-start SLO.

The business lane closes the design: billing integrates payment gateways per region, entitlements gate the DRM license service (no valid plan, no license โ€” enforcement happens at key issuance, not in the client), and household/sharing controls plus parental ratings are policy checks on the same entitlement path. Compliance โ€” regional ratings and censorship โ€” filters the catalog per territory just like Spotify's licensing windows.

!Enforce at the license, not the client

Any control that lives only in client code (sharing limits, parental controls, plan checks) will be bypassed. The DRM license issuance point is the single server-side chokepoint where entitlement enforcement actually holds.

Blueprint

Architecture Diagram

The narrated components above, laid out as an actual flow โ€” so you can see how a request moves through the system, not just read a list of pieces.

Ingest

1

Ingest

2

encoding

3

DRM

4

storage

5

Open Connect distribution

Playback service issues

1

Playback service issues manifest/license

2

clients stream from CDN

Personalization service chooses

1

Personalization service chooses rows/artwork via ML

Telemetry

1

Telemetry

2

stream processing

3

monitoring dashboards

Billing/payment service integrates

1

Billing/payment service integrates with payment gateways

2

entitlements

Flow Diagram

How the API maps to this flow

  1. 1GET /api/homeโ€” personalized home screen.
  2. 2GET /api/playback/{id}/manifestโ€” returns ABR manifest + DRM license info.
  3. 3POST /api/telemetry/qoeโ€” client QoE metrics.
  4. 4POST /api/profiles/{id}/resumeโ€” update watch state.
  5. 5POST /api/studio/ingestโ€” upload new asset metadata.

?But why does this actually hold up at scale?

30M concurrent viewers @5 Mbps -> 150 Tbps egress. Majority handled via Open Connect boxes.

Video walkthrough

System Design Interview: Design Netflix

Exponent ยท 27 min

Content delivery, open connect and personalisation, framed as an interview answer rather than a lecture.

Work the prompt yourself first โ€” guided practice grades your own answer step by step. Watching someone else design it feels like progress and teaches you far less.

Interview flow

Dialogue timeline

Interviewer

Summarize the flow end-to-end.

Candidate

Studio ingest -> encoding -> DRM -> storage/CDN -> playback + personalization -> telemetry + billing.

Interviewer

Explain Open Connect.

Candidate

Netflix ships caching appliances to ISPs. Content pushed ahead; clients stream from local nodes via ABR. Control plane reroutes when nodes fail.

Interviewer

Personalization approach?

Candidate

Event stream feeds ML models to rank rows/artwork per profile. Batch + real-time features served via home API.

Scoping

Requirements & trade-offs

Functional Requirements

  • โ€”Content ingest with localization, subtitles, DRM.
  • โ€”Encoding/transcoding pipeline (multi-bitrate, multi-codec).
  • โ€”Playback with ABR, downloads for offline, multi-device support.
  • โ€”Personalized home rows, search, continue watching, watch parties.
  • โ€”Telemetry for QoE, billing, profiles, parental controls.

Non-Functional Requirements

  • โ€”Playback start < 1.5 s.
  • โ€”Streaming reliability 99.99%.
  • โ€”Regional compliance (ratings, censorship, payments).
  • โ€”Security: DRM, anti-piracy, credential sharing limits.

Blueprint

Architecture modules

Module 1

API Endpoints

  • โ€ขGET /api/home - personalized home screen.
  • โ€ขGET /api/playback/{id}/manifest - returns ABR manifest + DRM license info.
  • โ€ขPOST /api/telemetry/qoe - client QoE metrics.
  • โ€ขPOST /api/profiles/{id}/resume - update watch state.
  • โ€ขPOST /api/studio/ingest - upload new asset metadata.

Module 2

Back-of-the-Envelope

  • โ€ข30M concurrent viewers @5 Mbps -> 150 Tbps egress. Majority handled via Open Connect boxes.
  • โ€ขCatalog ~10K titles, each multiple renditions -> tens of PB storage.
  • โ€ขTelemetry: billions of events/day -> Kafka + analytics lake.
  • โ€ขPersonalization features: 200M profiles * 2 KB -> 400 GB in feature store.

Module 3

System Diagram Notes

  • โ€ขIngest -> encoding -> DRM -> storage -> Open Connect distribution.
  • โ€ขPlayback service issues manifest/license; clients stream from CDN.
  • โ€ขPersonalization service chooses rows/artwork via ML.
  • โ€ขTelemetry -> stream processing -> monitoring dashboards.
  • โ€ขBilling/payment service integrates with payment gateways + entitlements.

Module 4

Design Playbook

  • โ€ขClarify ingest + encoding pipeline.
  • โ€ขExplain Open Connect and ABR playback.
  • โ€ขDiscuss personalization experimentation.
  • โ€ขCover QoE monitoring, incident response.
  • โ€ขMention DRM/offline downloads/account sharing controls.