Design Netflix / Video Streaming

Meta's "Design Netflix / Video Streaming" interview question focuses on architecting a scalable, fault-tolerant platform for on-demand video delivery, often tagged with data engineering, recommendations, machine learning, system design, mobile/backend, and CDN elements. No single canonical "full problem statement" exists publicly from Meta, as questions evolve, but it's consistently framed around designing a Netflix-like service handling global users, adaptive streaming, personalization, and high availability.[1][2][3]

Core Problem Statement

Design a video streaming platform like Netflix that supports millions of concurrent users worldwide. Key goals include low-latency playback, personalized recommendations, cross-device resume, content upload/processing, and fault-tolerant delivery via CDN. Clarify scope upfront: on-demand (not live), daily active users (DAU) of 100M+, peak 2M concurrent streams, 99.99% uptime, <2s startup time.[2][6][1]

Functional Requirements

• Users browse/search personalized homepages with recommendations based on viewing history.
• Upload videos with metadata; auto-transcode into adaptive bitrate (ABR) formats (240p-4K, 2-6s segments).
• Stream with play/pause/resume across devices (mobile, web, TV); support DRM and subtitles.
• Manage subscriptions/profiles gating access.
• Collect analytics (watch time, buffering) for ML feedback.[3][1][2]

Non-Functional Requirements

• Scale: 100M+ DAU, TBs of video data, 10PB+ storage.
• Latency: <2s cold start, <1s rebuffer <1%.
• Availability: Multi-region failover, geo-redundant.
• Cost: Optimize transcoding/egress via Open Connect-like CDN.
• Security: Auth, rate limiting, content protection.[4][1]

Input/Output Examples

No formal I/O formats like LeetCode, but example API flows include:

Browse Homepage (Recommendations)

• Input: GET /homepage?user_id=123 (headers: auth token).
• Output: JSON with carousels: { "rows": [{ "title": "Trending", "videos": [{ "id": "abc", "title": "Movie X", "thumbnail": "url", "genres": ["action"] }] }] }.[2]

Stream Video

• Input: GET /stream/{video_id}?user_id=123&position=120s (client reports bandwidth).
• Output: Manifest (HLS/DASH): { "video": "cdn_url_720p.m3u8", "audio": "audio.aac", "subtitles": "en.vtt" }; client fetches segments from CDN.[6][1]

Resume Playback

• Input: POST /watch-history { "user_id": 123, "video_id": "abc", "position": 300s, "device": "mobile" }.
• Output: 200 OK; on next play, serve from stored position.[2]

Upload Video

• Input: POST /upload (multipart: video file, metadata JSON).
• Output: 202 Accepted { "job_id": "xyz" }; poll /status/xyz for { "status": "ready", "renditions": ["240p", "1080p"] }.[2]

Constraints and Scale

• Storage: 10M videos, avg 100GB raw → 1PB+ post-transcode.
• Bandwidth: 1Tbps+ peak, 5Mbps avg stream.
• Compute: Transcode jobs (hours/video) via queues (e.g., AWS Elemental).
• No hard "constraints" like memory limits; focus on trade-offs (e.g., CDN hit rate >95%, ML recall@K).[1][3][4]