Design Netflix

Problem Statement

Design Netflix as a production service where growth exposes the first weak assumption in the original design. For Design Netflix, name the critical user action, the data that must remain correct, and the first bottleneck that appears when traffic grows.

Deep-Dive: Clarifying Questions for Netflix

1. What is the streaming volume? Netflix serves 200M+ subscribers watching 1 billion hours of video per week. During peak hours (8-10 PM local time), Netflix accounts for 15% of all downstream internet traffic in North America.
2. How does content delivery work? Netflix uses its own CDN (Open Connect) with servers placed inside ISP data centers. Do we design our own CDN or use a third-party?
3. What video quality levels? Netflix encodes each title in 10+ quality levels (240p to 4K HDR) across multiple codecs (H.264, VP9, AV1). Adaptive bitrate streaming switches quality based on bandwidth.
4. How important is the recommendation engine? 80% of content watched on Netflix comes from recommendations, not search. The recommendation system is arguably the most important technical component.
5. Do we need to handle global distribution? Netflix operates in 190+ countries with content licensing that varies by region. Some content is available in the US but not in Europe.
6. What about the video transcoding pipeline? When Netflix acquires a new title, it must be transcoded into 1,000+ versions (quality * codec * resolution combinations). How do we handle this at scale?

Specific Functional Requirements

1. Video Streaming: Stream video content with adaptive bitrate switching based on network conditions — quality changes should be invisible to the viewer
2. Content Catalog: Browse and search a catalog of 15,000+ titles with metadata in 30+ languages
3. Personalized Recommendations: Show each user a unique homepage ranked by predicted viewing interest using collaborative and content-based filtering
4. User Profiles: Support up to 5 profiles per account with independent viewing histories and recommendations
5. Continue Watching: Track playback position to the second so users can resume from any device
6. Content Delivery: Serve video from edge servers (CDN) close to the viewer for minimal buffering
7. Video Transcoding: Process new content into multiple quality levels and codecs within hours of acquisition

Specific API Endpoints

GET /api/v1/catalog/browse?profile_id=abc&genre=action&page=1
  Response: { "rows": [{ "title": "Trending Now", "items": [...] }, { "title": "Because You Watched...", "items": [...] }] }

GET /api/v1/playback/start?title_id=12345&profile_id=abc
  Response: { "manifest_url": "https://cdn.example.com/12345/manifest.mpd", "resume_position": 1847, "subtitles": [...], "audio_tracks": [...] }

POST /api/v1/playback/heartbeat
  Body: { "title_id": 12345, "position": 1920, "quality": "1080p", "buffer_health": 30 }
  (Sent every 10 seconds during playback)

GET /api/v1/search?q=stranger+things&profile_id=abc
  Response: { "results": [...], "suggestions": ["Stranger Things", "Strange Planet"] }

POST /api/v1/ratings
  Body: { "title_id": 12345, "profile_id": "abc", "rating": "thumbs_up" }

Specific Data Model

Content Metadata (PostgreSQL/Cassandra)

Viewing History (Cassandra): Partitioned by user_id for fast "resume watching" queries.

• (user_id, title_id) -> { position_seconds, last_watched, completed, device }

Recommendation Model Outputs (Redis/Cassandra): Pre-computed ranked lists per user.

• user_id -> [title_id_1, title_id_2, ...] with scores, refreshed every few hours by ML batch pipeline

CDN Manifest (Edge Cache): DASH/HLS manifests that tell the player where to fetch each 4-second video chunk at each quality level. Cached at edge servers with short TTL (5 min) so quality adaptation works in real-time.

Specific Back-of-the-Envelope Numbers

Traffic:

• 200M subscribers, ~100M concurrent streams during global peak
• Each stream: one manifest request + one chunk request every 4 seconds = 25M chunk requests/second at peak
• Recommendation page loads: 200M sessions/day * 10 page loads = 2B recommendation requests/day

Storage:

• Content library: 15,000 titles * 1,000 encoding profiles * average 1 GB per profile = 15 PB of encoded video
• Viewing history: 200M users * average 500 titles watched * 50 bytes = 5 TB
• Recommendation data: 200M users * 2 KB pre-computed rankings = 400 GB (fits in Redis cluster)

Bandwidth:

• Average stream: 5 Mbps (1080p) = 625 KB/second
• 100M concurrent streams * 625 KB/s = 62.5 TB/second = 500 Tbps (this is why Netflix built their own CDN)
• Netflix's Open Connect serves 95%+ of this from ISP-embedded servers

Video transcoding:

• New title: 2 hours of 4K source = ~100 GB raw
• Encode into 1,000+ profiles: ~100 hours of compute time
• Use a massive parallel encoding farm (AWS EC2 spot instances or dedicated encoding hardware)

Original DosiBridge notes for Design Netflix

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Design Netflix is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Core Entity: For Design Netflix, decide the core entity before choosing tools; otherwise the design looks clean but fails when netflix changes.
• Read/Write Path: For Design Netflix, decide the read/write path before choosing tools; otherwise the design looks clean but fails when netflix changes.
• Contention Point: For Design Netflix, decide the contention point before choosing tools; otherwise the design looks clean but fails when netflix changes.
• Abuse Path: For Design Netflix, decide the abuse path before choosing tools; otherwise the design looks clean but fails when netflix changes.
• Recovery Workflow: For Design Netflix, decide the recovery workflow before choosing tools; otherwise the design looks clean but fails when netflix changes.

Design Netflix correctness boundary

For this problem, separate the user-visible action from background work. The correctness boundary is the smallest state transition that must not be duplicated, lost, or reordered. Naming that boundary makes the solution more original than a stock API/database/cache template.

Design Netflix scaling bottleneck

The first bottleneck should be described in the language of this system: a hot timeline, a contested seat, a busy wallet ledger, a media-processing queue, or a search index update delay. That bottleneck decides which component deserves the deepest interview discussion.

Production review question

If Design Netflix suddenly receives 10x traffic, which entity becomes contested first, and what queue, lock, shard, or cache protects that entity without hiding correctness bugs?

Practical metric to track

Track netflix health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Design Netflix, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Sources

• Design Netflix — Reference
• Source: System-Design-Overview