Design Netflix
Design Netflix at 250M subscribers, 30% of US internet traffic. Covers the transcoding pipeline (master mezzanine -> 15 encodings per title -> HLS/DASH segments -> DRM), the Open Connect CDN (appliances inside ISPs), adaptive bitrate streaming (player switches bitrate per segment based on throughput), and pre-computed recommendations refreshed nightly. The deep dive walks through why Netflix built its own CDN and how ABR works.
How it works
What are we designing? Netflix — a global on-demand video streaming service. Users browse a catalog of movies/shows, click play, and the video starts streaming within 2 seconds and plays smoothly even on flaky mobile networks. Netflix must serve 250M+ subscribers across 190 countries, handle 30%+ of US peak internet traffic, and produce original content that must be ingested, transcoded, and delivered worldwide.
The defining challenges are video at scale (each stream is multi-Mbps, sustained for hours) and adaptive playback (the video must smoothly switch quality as the user's bandwidth fluctuates). The CDN strategy is the heart of this case study — Netflix famously built its own CDN (Open Connect) because generic CDNs couldn't handle the load.
Functional requirements.
- Browse catalog (titles, posters, metadata).
- Search titles.
- Play a video on demand; supports resume, scrub, skip intro.
- Adaptive bitrate: video quality adjusts to network conditions.
- Subtitles / audio tracks in multiple languages.
- Continue-watching, personalized recommendations.
Non-functional requirements.
- Time-to-first-frame: < 2 s (longer = users abandon).
- Rebuffer ratio: < 1% of play time (rebuffering causes churn).
- Availability: 99.99% (Saturday-night outages are news).
- Catalog size: 100K+ titles, each in 5+ bitrates and 5+ resolutions.
- Scale: 250M subscribers, 200M+ hours streamed/day.
Non-goals. No live streaming, no user-generated content (that's YouTube).
Capacity estimation.
Streaming volume. 250M subscribers, average 2 hours/day viewing = 500M hours/day = ~6 TB/day compressed at 5 Mbps = ~30 PB/day of egress. Netflix is ~15% of global internet traffic.
Storage. Each title is encoded in ~5 bitrates (240p to 4K) and multiple codecs (H.264, HEVC, AV1). A 2-hour movie at 4K = ~7 GB per encoding; 5 encodings x 3 codecs = ~100 GB per title. 100K titles x 100 GB = 10 PB of media storage. Stored on object storage (S3) and pushed to CDN edges.
Catalog metadata. Each title ~10KB (title, synopsis, cast, posters, etc.). 100K titles x 10 KB = 1 GB. Trivial — fits in a single database.
CDN edge capacity. Netflix Open Connect Appliance (OCA) caches sit inside ISPs. Each OCA holds ~100 TB-2 PB. There are 1000+ OCAs globally.
Recommendations. Pre-compute top-N recommendations per user, refreshed daily. 250M users x 100 recs x 8 bytes = 200 GB in Redis.
Watch history. 250M users x ~1000 watched items x 100 bytes = 25 GB in Cassandra.
APIs.
GET /v1/catalog?genre=... -> titles list (paginated)
GET /v1/titles/:id -> metadata + available encodings
GET /v1/search?q=... -> search results
POST /v1/playback/start (title_id, device, bitrate_hint)
-> { manifest_url, license_url, cdn_node } (HLS/DASH manifest URL)
POST /v1/playback/progress (every 30s, for resume + analytics)
GET /v1/recommendations -> personalized top-NPlayback is HLS or DASH: the player fetches a manifest (m3u8 or mpd) listing available bitrates; the player requests segments (2-10s video chunks) and decides which bitrate to fetch based on observed throughput.
Data model.
Titles (sharded SQL):
titles (id BIGINT PK, name, synopsis, runtime_sec, release_year,
maturity_rating, default_poster_url)
title_genres (title_id, genre)
title_cast (title_id, actor_id, role)Encodings (object storage S3 + CDN edge):
encodings (id, title_id, resolution ENUM('240p','480p','720p','1080p','4K'),
codec ENUM('h264','hevc','av1'), bitrate_kbps, manifest_url)Watch progress (Cassandra, partitioned by user_id):
watch_progress (user_id, title_id, position_sec, ts, PRIMARY KEY ((user_id), title_id))Recommendations (Redis, pre-computed):
key: recs:{user_id}
value: LIST of title_ids, top 100
TTL: 24h (refreshed daily)Manifest (HLS m3u8 file, served from CDN):
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/playlist.m3u8Each sub-playlist lists 10s .ts segments.
Deep dive: adaptive bitrate streaming and the Open Connect CDN.
Why ABR exists. A user's bandwidth fluctuates constantly — WiFi interference, cellular handoff, household members streaming. If Netflix sent a fixed 5 Mbps stream and the user's throughput dropped to 2 Mbps, the player would rebuffer (stall). ABR (Adaptive Bitrate) solves this by splitting the video into 2-10s segments at multiple bitrates (240p, 480p, 720p, 1080p, 4K) and letting the player switch on the fly.
ABR algorithm. A typical ABR player (e.g. dash.js, Shaka):
- Fetch the manifest, list available bitrates.
- Start with the lowest bitrate segment (fast time-to-first-frame).
- Measure throughput while fetching.
- Estimate next-segment bandwidth = EWMA of recent throughput.
- Pick the highest bitrate whose bandwidth <= 0.7 x estimated throughput (0.7 buffer factor avoids edge-of-cliff rebuffers).
- Maintain a buffer of ~10s ahead so brief throughput dips don't rebuffer.
Why Netflix built Open Connect. In 2011-2012, Netflix used third-party CDNs (Akamai, Limelight, Level3). At Netflix's scale (~30% of US internet traffic), generic CDNs couldn't economically deliver, and Netflix wanted more control over where bytes were cached (e.g. pre-position new episodes on edges before release). Open Connect: Netflix ships physical appliances (OCAs) into ISP data centers. Each OCA holds 100 TB - 2 PB. ISPs get free peering (Netflix traffic doesn't traverse their paid transit); Netflix gets free edge capacity. Win-win.
OCA fill strategy. New content is pushed to OCAs proactively (before release) based on predicted demand. Popular content is on every OCA; long-tail content is served from regional origins on cache miss.
Transcoding pipeline. Master mezzanine files (huge, ~10s of GB per title) are transcoded in parallel on AWS EC2 spot instances. Each encoding is a separate FFmpeg job; 15 encodings per title takes hours but is done once at ingestion. AV1 codec (newer, ~30% smaller than HEVC) is transcoded last because it's 10x slower.
DRM. Every segment is encrypted (Widevine for Android/Chrome, FairPlay for iOS/Safari, PlayReady for Windows). The Playback Service issues a short-TTL license to the device; the device decrypts on playback. Without a license, segments are useless bytes.
Bottlenecks and failure modes.
-
OCA cache miss. A user requests a long-tail title not on their local OCA. Mitigation: OCA fetches from regional origin (adds 50-200ms latency for the first segment); after that, cached.
-
ISP outage. An ISP's OCA goes offline; users in that ISP fall back to a regional origin. Mitigation: regional origins have capacity; DNS health checks redirect users.
-
Release-day spike. A new Stranger Things episode drops; everyone tries to watch at once. Mitigation: pre-position the episode on every OCA 24h before release; warm edge caches.
-
ABR over-reaction. The player sees a brief throughput dip and switches down to 240p, then back up — visible quality flicker. Mitigation: ABR algorithms (e.g. BOLA, MPC) use buffer-aware logic to avoid flapping.
-
DRM license server failure. Without a license, no playback. Mitigation: license servers are HA multi-region; client caches license for the session.
-
Transcoding bottleneck. AV1 transcode is 10x slower than HEVC; a new title can take days to fully transcode. Mitigation: parallelize across thousands of spot instances; accept that AV1 lags other codecs by weeks.
-
Recommendations freshness. Recs are recomputed nightly; a user who binge-watches a show may see stale recs the next day. Mitigation: trigger a rec recompute on significant watch events.
-
Subtitle / audio track load. A title with 30 subtitle languages and 10 audio tracks has 300 track combinations. Mitigation: subtitles and audio are stored as separate tracks; the player fetches only the one selected.
Scaling strategy and trade-offs.
CDN scaling. Open Connect scales by adding more OCAs inside ISPs. Each OCA is a commodity x86 server with disks; Netflix ships them free to ISPs.
Transcoding scaling. Parallelize per (title, resolution, codec) job on spot instances. Cost-optimized: run on spot, retry on eviction.
Catalog scaling. 100K titles is small for a database; even 10M titles would fit in a sharded Postgres. The bottleneck is search and discovery, not storage.
Recommendations scaling. Pre-compute top-N per user nightly using Spark. 250M users x 1000 watched items x cosine similarity = trillions of operations, but Spark handles it in hours.
Multi-region. Catalog and metadata are globally replicated. Streaming is inherently regional (each user's nearest OCA).
Trade-offs made explicit.
- We chose Open Connect (own CDN) — gained cost control and edge caching policy, lost the operational simplicity of a managed CDN.
- We chose HLS/DASH segments of 10s — gained fine-grained ABR switching, lost segment overhead (more HTTP requests) and slight latency.
- We chose multi-codec (H.264 + HEVC + AV1) — gained bandwidth savings (AV1 is 30% smaller), lost transcoding cost and storage.
- We chose pre-computed recommendations nightly — gained fast reads, lost freshness (recs up to 24h stale).
- We chose DRM on every segment — gained content protection (studios require it), lost license-server dependency for playback.
Why does Netflix split videos into 10-second segments at multiple bitrates?
Pick one answer.
Why did Netflix build its own CDN (Open Connect) instead of using Akamai/Cloudflare?
Pick one answer.
Engineering mental model
Mental model. Think of Design Netflix as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Design Netflix mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Design Netflix, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = design_netflix(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Design Netflix
Change the variables below and predict what breaks first in Design Netflix. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Design Netflix, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Design Netflix. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Design Netflix?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Design Netflix, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Design Netflix, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for Design Netflix: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using Design Netflix. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Adaptive bitrate (segment switching) handles flaky networks gracefully.
- +Open Connect (appliances inside ISPs) gives free peering and edge caching control.
- +Multi-codec (H.264/HEVC/AV1) saves 30% bandwidth for capable devices.
- +Pre-computed nightly recommendations keep reads fast.
- −Open Connect is operationally complex — physical appliances, ISP relationships.
- −AV1 transcoding is 10x slower than HEVC — new titles lag in AV1 by weeks.
- −Recommendations are up to 24h stale.
- −DRM license server is a playback dependency.
How this breaks in production
- OCA cache miss on long-tail titles — needs regional origin fallback.
- ISP / OCA outage — needs DNS health-check redirect to regional origin.
- Release-day spike — needs proactive pre-positioning on edges 24h before.
- ABR over-reaction causing quality flicker — needs buffer-aware algorithms (BOLA/MPC).
- DRM license server failure — needs multi-region HA + client-side license cache.
Don't fall into these traps
- •Serving a single giant video file instead of segmented HLS/DASH — no ABR possible.
- •Using a managed CDN at Netflix's scale — uneconomical.
- •Single-codec encoding — wastes bandwidth for capable devices.
- •Computing recommendations on read — blows latency budget.
- •Single-region DRM license server — playback breaks on regional outage.
Real systems using this
How real systems implement this
- Netflix Open Connect — Custom CDN with physical appliances (OCAs) inside ISP data centers. Netflix handles origin and transcoding on AWS; OCAs serve bytes from inside ISPs. Documented in their tech blog.
- HLS / DASH — Open standards for ABR streaming. HLS (HTTP Live Streaming, Apple) uses .m3u8 manifests + .ts segments. DASH (Dynamic Adaptive Streaming over HTTP, MPEG) uses .mpd manifests + .m4s segments.
- Disney+ Hotstar — India-scale streaming (100M+ concurrent viewers for cricket). Uses Akamai + multi-CDN strategy and aggressive pre-warming for live events.
Practice saying it out loud
- Q1Design Netflix. How do you handle 30% of US internet traffic?
- Q2Why does Netflix use 10-second video segments at multiple bitrates?
- Q3Why did Netflix build Open Connect instead of using Akamai?
- Q4How does the player switch video quality during playback?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Design YouTube