System Design Arena
System Design: Netflix
Deliver premium video content globally with ABR streaming, personalization, and studio workflows.
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.
Scorecard
What the interviewer is evaluating
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.
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.
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.
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.
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.
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
Ingest
encoding
DRM
storage
Open Connect distribution
Playback service issues
Playback service issues manifest/license
clients stream from CDN
Personalization service chooses
Personalization service chooses rows/artwork via ML
Telemetry
Telemetry
stream processing
monitoring dashboards
Billing/payment service integrates
Billing/payment service integrates with payment gateways
entitlements
Flow Diagram
How the API maps to this flow
- 1
GET /api/homeโ personalized home screen. - 2
GET /api/playback/{id}/manifestโ returns ABR manifest + DRM license info. - 3
POST /api/telemetry/qoeโ client QoE metrics. - 4
POST /api/profiles/{id}/resumeโ update watch state. - 5
POST /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.