The Question
Design

Global Video Streaming Platform Design

Design a globally distributed video-on-demand (VOD) streaming service similar to Netflix. The system must support millions of concurrent viewers, provide low-latency playback start, and handle massive video asset processing. Address how the system manages adaptive bitrate streaming, content delivery at the edge, and the high-write throughput required for tracking user playback progress across multiple devices. Discuss trade-offs between availability and consistency in the context of a global user base.
NoSQL
Cassandra
Redis
Kafka
S3
CDN
Elasticsearch
Microservices
DRM
HLS
DASH
Questions & Insights

Clarifying Questions

What is the scale of the system in terms of users and content?Assumption: 200M total subscribers, 50M DAU, and a library of 20,000 titles.
Does the design include the content ingestion and transcoding pipeline or just the delivery?Assumption: Both are required to explain how video becomes available, though the focus is on high-availability delivery.
Is live streaming in scope?Assumption: No, the MVP focuses on Video-on-Demand (VOD) to adhere to YAGNI.
What are the playback performance targets?Assumption: Start-up latency < 2 seconds and zero mid-stream buffering for 95% of users.

Thinking Process

The core challenge of Netflix is not the "website" but the massive data distribution and the compute-heavy preparation of video assets.
How do we handle massive video files? We break videos into small chunks and transcode them into multiple resolutions and bitrates for Adaptive Bitrate Streaming (ABR).
How do we ensure low-latency playback globally? We push the heavy video bits to the Edge using a Content Delivery Network (CDN), while keeping the "brains" (metadata/auth) in a central cloud.
How do we handle the high write-load of "bookmarking"? As users watch, we frequently save their position. This requires a high-write throughput NoSQL store.
Final Architecture: A decoupled system with a heavy-duty asynchronous Transcoding Pipeline, a highly available Metadata Service, and a globally distributed CDN-based Delivery Layer.

Bonus Points

Chaos Engineering: Implementing tools like Chaos Monkey to randomly terminate instances in production to ensure the system remains resilient.
Adaptive Bitrate Switching (ABR): Using manifest files (M3U8/MPD) to allow the player to switch quality mid-stream based on network conditions.
Open Connect Strategy: Discussing the use of ISP-colocated appliances (OCA) to reduce backhaul costs and latency compared to standard public CDNs.
Micro-Frontends: Decoupling the UI logic for different devices (TV vs. Mobile) to allow independent deployments and specialized performance optimizations.
Design Breakdown

Functional Requirements

Core Use Cases:
Users can browse and search for movie/TV show metadata.
Users can stream video in various qualities (720p, 1080p, 4K) based on bandwidth.
Users can save their "watching" state (bookmarks).
Admins can upload new content and trigger transcoding.
Scope Control:
In-scope: VOD playback, Metadata browsing, Transcoding pipeline, Search.
Out-of-scope: Live streaming, Social features (comments/friends), Billing/Subscription management (assumed external/third-party).

Non-Functional Requirements

Scale: Support 50M DAU and 10M+ concurrent video streams.
Latency: Discovery/Browsing APIs < 200ms; Video start < 2s.
Availability & Reliability: 99.99% (High availability is prioritized over strong consistency for viewing).
Consistency: Eventual consistency for "Continue Watching" across devices is acceptable.
Fault Tolerance: Regional failover for API services; CDN redundancy for video.
Security: Content protection via DRM (Digital Rights Management) and secure playback URLs.

Estimation

Traffic:
50M DAU * 5 requests/day = 250M daily requests (~3k QPS avg).
Peak concurrent: 10M users.
Storage:
20k titles 5 formats 10GB (avg high-def) = 1 Petabyte.
User history/metadata: 200M users * 1KB = 200GB (easily fits in NoSQL).
Bandwidth:
10M concurrent users * 5 Mbps (average stream) = 50 Tbps (handled primarily by CDN).

Blueprint

Concise Summary: The system utilizes a microservices architecture hosted in the cloud for control plane logic (Metadata, Auth, Bookmarks) and an asynchronous pipeline for video processing, leveraging a global CDN for the data plane (video delivery).
Major Components:
Transcoding Service: Asynchronously converts raw uploads into multiple bitrates/formats.
API Gateway: Routes traffic, handles Auth, and provides Rate Limiting.
Catalog Service: Serves movie metadata and search results.
Playback Service: Generates time-limited signed URLs for the CDN.
CDN (Open Connect): Stores and serves video chunks to the end-user.
Simplicity Audit: Avoids complex live-streaming synchronization; uses standard S3-based storage for the source of truth.
Architecture Decision Rationale:
Why this architecture?: Decoupling the "Control Plane" (Metadata) from the "Data Plane" (Video) allows us to scale them independently. NoSQL (Cassandra) is chosen for high-write availability for user history.
Functional Satisfaction: Covers the full lifecycle from upload to playback.
Non-functional Satisfaction: CDN ensures low latency; Microservices ensure high availability and scalability.

High Level Architecture

Sub-system Deep Dive

Edge (Optional)

Content Delivery & Traffic Routing:
CDN: Uses a multi-CDN strategy (e.g., Cloudfront + Netflix Open Connect). Static assets (images) and video chunks are cached at the edge.
DNS: Latency-based routing to the nearest AWS region or CDN PoP.
Security & Perimeter:
API Gateway: Handles JWT-based authentication and TLS termination.
Rate Limiting: Applied per User-ID to prevent scraping of the catalog.

Service

Topology & Scaling: Stateless microservices deployed in EKS (Kubernetes) across multiple Availability Zones (Multi-AZ).
API Schema Design:
GET /v1/metadata/{id}: Returns title, description, cast.
GET /v1/playback/{id}: Returns manifest file (M3U8) and signed CDN URLs.
POST /v1/history: Updates current offset (idempotent with timestamp).
Resilience:
Hystrix-style circuit breakers for the User History service to ensure browsing still works even if "Continue Watching" is down.
Observability:
Centralized ELK stack for logs; Prometheus for QPS/Error-rate metrics.

Storage

Access Pattern:
Metadata: High read/low write.
User History: Extremely high write (heartbeat every 10s during playback).
Database Table Design:
Metadata (PostgreSQL): movie_id (PK), title, description, release_date, rating_id.
User History (Cassandra): Partition Key: user_id, Clustering Key: movie_id, offset_seconds, last_updated.
Technical Selection:
Cassandra: Chosen for its ability to handle high-volume time-series writes across regions without a single point of failure.
Elasticsearch: Used for the search bar to support fuzzy matching and prefix search.

Cache

Purpose: Reduce load on the Metadata DB and speed up the homepage.
Key-Value Schema: movie_id -> JSON(metadata_blob).
Technical Selection: Redis.
Failure Handling: If Redis fails, fall back to the Postgres DB. Use a "Write-around" strategy where DB is updated first, and cache is invalidated.

Messaging

Purpose: Orchestrating the transcoding pipeline and decoupling view-event analytics.
Event Schema: video_id, status (uploaded/processing/complete), format, resolution.
Technical Selection: Kafka.
Rationale: High throughput for billions of viewing events used for the recommendation engine (YAGNI for MVP, but good for future-proofing).

Data Processing

Processing Model: Chunk-based parallel transcoding.
Processing DAG:
Upload raw file to S3.
Split file into 2-second chunks.
Transcode chunks in parallel into H.264/H.265 at 360p, 720p, 1080p.
Aggregate chunks into manifest files.
Technical Selection: AWS Lambda or EC2 Spot Instances with FFmpeg.
Rationale: Cost-effective for bursting workloads.

Infrastructure (Optional)

Observability: Distributed tracing using Jaeger to track a request from the Gateway to the DB.
Distributed Coordination: Using ZooKeeper (bundled with Kafka) for managing offsets and leader election in the transcoding workers.
Wrap Up

Advanced Topics

Trade-offs: We choose Availability over Consistency (AP). If a user watches a movie on their phone and immediately opens their laptop, it's okay if the "Continue Watching" is 30 seconds behind.
Reliability: Video chunks are replicated across multiple CDN nodes. If one OCA (Open Connect Appliance) fails, the client manifest automatically points to a backup URL.
Bottleneck Analysis: The main bottleneck is the Transcoding duration for 4K content. We mitigate this by prioritizing "New Releases" in the processing queue.
Security: DRM (Widevine/FairPlay) is used to prevent stream ripping. URL signing prevents unauthorized users from sharing direct video links.
Distinguishing Insights: Netflix actually uses a "Pre-positioning" strategy. Based on viewing trends, they push popular movies to the CDNs before the Friday night peak to avoid saturating the ISP backbone during high-demand hours.