Chapter 46: Design YouTube/Netflix

Video Upload, Transcoding, Adaptive Streaming & Recommendations

Introduction

Designing a video streaming platform like YouTube or Netflix is one of the most complex system design challenges. It involves handling massive video uploads, transcoding to multiple formats, serving billions of video streams with low latency, implementing adaptive bitrate streaming, building recommendation engines, and scaling to serve 2 billion monthly active users.

Interview Tip

Start broad, then narrow focus. Video platforms are massive systems. Begin by clarifying scope with your interviewer: Are we focusing on upload pipeline? Streaming infrastructure? Recommendations? Content moderation? Live streaming? VOD? This chapter covers the core upload, transcoding, and streaming pipeline, plus recommendations.

Key distinction: YouTube (user-generated content, massive upload volume) vs Netflix (curated catalog, premium quality). Ask which model to optimize for.

This case study follows the interview format: requirements gathering, capacity estimation, high-level design, deep dives into critical components, and tradeoff discussions.

1. Requirements

Functional Requirements

Video Upload: Users can upload videos (up to 12 hours long, multiple GB in size)
Video Streaming: Users can watch videos with adaptive quality based on network conditions
Video Search: Users can search videos by title, tags, description, creator
Recommendations: Personalized video recommendations based on viewing history and preferences
Social Features: Like, comment, subscribe, share (simplified for this design)
Creator Dashboard: Upload status, analytics, monetization metrics
Content Moderation: Detect and flag inappropriate content (out of scope for deep dive)

Scope Clarification: We'll focus on the upload pipeline, transcoding infrastructure, adaptive streaming, and recommendations. Features like live streaming, content ID/copyright, and detailed analytics are mentioned but not deeply designed.

Non-Functional Requirements

Massive Scale: 2 billion monthly active users (MAU)
Upload Volume: 500 hours of video uploaded per minute
Low Latency: Video starts playing within 1-2 seconds (first byte time)
High Availability: 99.99% uptime for streaming (4 nines)
Reliability: No data loss for uploaded videos
Global Distribution: Low-latency access from any geographic region
Cost Efficiency: Optimize storage and bandwidth costs (petabytes of data)
Quality: Support 4K, 1080p, 720p, 480p, 360p, 144p adaptive streaming
Consistency: Eventual consistency acceptable for view counts, likes; strong consistency for uploads

Interview Tip

Clarify read vs write ratio. YouTube is extremely read-heavy (10,000:1 or higher). This drives design decisions: heavy caching, CDN-first architecture, eventual consistency for social signals. Uploads need reliability but not ultra-low latency.

2. Capacity Estimation

Storage Estimation

Upload Rate: - 500 hours of video per minute - 500 hours/min × 60 min/hr × 24 hr/day = 720,000 hours/day - ~262 million hours per year Storage per video (assuming 1 hour video): Original (high quality): - Raw: ~10 GB/hour (depending on codec) Transcoded versions (per hour of video): - 4K (3840x2160, 20 Mbps): ~9 GB - 1080p (1920x1080, 8 Mbps): ~3.6 GB - 720p (1280x720, 5 Mbps): ~2.25 GB - 480p (854x480, 2.5 Mbps): ~1.125 GB - 360p (640x360, 1 Mbps): ~450 MB - 144p (256x144, 0.3 Mbps): ~135 MB Total transcoded: ~16.5 GB per hour Total per uploaded hour (original + transcoded): ~26.5 GB per hour of video Daily storage growth: 720,000 hours/day × 26.5 GB/hour = 19,080,000 GB/day = ~19 PB per day Annual storage growth: 19 PB/day × 365 days = ~6,935 PB/year = ~7 EB/year Actual optimization: - Not all videos transcoded to 4K (only if original is 4K+) - Older/less popular videos stored in cold storage (cheaper) - Compression improvements (H.265/HEVC, AV1 codec) - Estimate: ~10-12 PB/day actual growth

Storage Tiers: Hot storage (recent/popular videos, fast SSD) vs Cold storage (old/unpopular videos, cheaper HDD or archive). YouTube uses tiered storage with automatic migration based on access patterns.

Bandwidth Estimation

Assumptions: - 2 billion MAU - Average 30 minutes watch time per user per day - Average bitrate: 2 Mbps (mixed quality) Daily watch time: 2B users × 30 min/user = 60 billion minutes/day = 1 billion hours/day Bandwidth per day: 1B hours × 2 Mbps average × 3600 sec/hr = 7.2 trillion Mb/day = 900 TB/day = 900,000 GB/day Peak bandwidth (assuming 3x average during peak hours): Peak: ~2.7 PB/day during peak 8-hour window = ~337.5 TB/hour = ~94 GB/second = 752 Gbps Actual YouTube scale (public estimates): - Over 1 billion hours watched per day - Petabytes of bandwidth per day - Served via multi-tier CDN (Google's global network + third-party CDNs)

QPS Estimation

Video upload QPS: 500 hours/min uploaded = 500 uploads/min (if avg video = 1 hour) Actual: videos range from seconds to hours, estimate ~50,000 uploads/min = ~833 uploads/second (peak could be 3-5x) Video playback initiation QPS: 1B hours watched/day = 41.7M hours/hour = 11,574 hours/second If avg watch session = 30 min = 0.5 hour, then ~23,000 playback starts/sec Peak: ~70,000 playback starts/second API QPS (metadata, search, recommendations): 2B MAU, assume 50% DAU = 1B DAU 1B users × 20 API calls/day (searches, recommendations, metadata) = 20B calls/day = 231,000 QPS average Peak: ~700,000 QPS CDN edge requests (video segments): HLS/DASH: ~10-second segments 1B hours watched/day = 360M segments/sec Distributed across thousands of edge servers globally

Interview Tip

Don't get lost in precision. Capacity estimation should take 3-5 minutes in an interview. Use round numbers, state assumptions clearly, and focus on orders of magnitude. The goal is to demonstrate you understand the scale and can do back-of-envelope math.

3. High-Level Architecture

The system consists of several major subsystems: upload pipeline, transcoding infrastructure, storage layer, CDN distribution, API gateway, recommendation engine, and metadata services.

graph TB
    subgraph "Client Layer"
        WebApp[Web Application]
        MobileApp[Mobile App]
        SmartTV[Smart TV App]
    end

    subgraph "Edge Layer"
        CDN[Multi-Tier CDN
Cloudflare, Akamai, Fastly]
        EdgeCache[Edge Caching Layer]
    end

    subgraph "API Gateway & Load Balancing"
        Gateway[API Gateway
Rate Limiting, Auth]
        LB[Load Balancer]
    end

    subgraph "Application Services"
        UploadService[Upload Service]
        MetadataService[Metadata Service]
        StreamService[Streaming Service]
        SearchService[Search Service]
        RecommendationService[Recommendation Service]
        UserService[User Service]
        AnalyticsService[Analytics Service]
    end

    subgraph "Processing Layer"
        UploadQueue[Upload Queue
SQS/Kafka]
        TranscodingWorkers[Transcoding Worker Pool
FFmpeg Workers]
        ThumbnailWorkers[Thumbnail Generator]
        MLPipeline[ML Pipeline
Recommendations, Content Moderation]
    end

    subgraph "Storage Layer"
        ObjectStorage[Object Storage
S3/GCS
Original Videos]
        TranscodedStorage[Transcoded Video Storage
Multiple Resolutions]
        MetadataDB[(Metadata DB
PostgreSQL/MySQL)]
        VideoSearchDB[(Search Index
Elasticsearch)]
        CacheLayer[Redis Cache
Metadata, User Sessions]
        AnalyticsDB[(Analytics DB
ClickHouse/BigQuery)]
    end

    WebApp --> CDN
    MobileApp --> CDN
    SmartTV --> CDN
    CDN --> EdgeCache
    EdgeCache --> Gateway
    Gateway --> LB
    LB --> UploadService
    LB --> MetadataService
    LB --> StreamService
    LB --> SearchService
    LB --> RecommendationService
    LB --> UserService

    UploadService --> UploadQueue
    UploadService --> ObjectStorage
    UploadQueue --> TranscodingWorkers
    UploadQueue --> ThumbnailWorkers
    TranscodingWorkers --> TranscodedStorage
    ThumbnailWorkers --> TranscodedStorage

    MetadataService --> MetadataDB
    MetadataService --> CacheLayer
    StreamService --> TranscodedStorage
    StreamService --> CDN
    SearchService --> VideoSearchDB
    RecommendationService --> MLPipeline

    AnalyticsService --> AnalyticsDB

    style CDN fill:#667eea,color:#fff
    style TranscodingWorkers fill:#4caf50,color:#fff
    style MLPipeline fill:#ff9800,color:#fff

Key Architectural Principles:

Separation of Concerns: Upload, transcoding, storage, serving are decoupled via queues
CDN-First: 90%+ of traffic served from edge locations, not origin servers
Eventual Consistency: View counts, likes, comments can be eventually consistent
Queue-Based Processing: Transcoding is asynchronous, decoupled from upload
Stateless Services: All application services are stateless for horizontal scaling

4. Video Upload Pipeline

The upload pipeline handles large video files (GBs), performs transcoding to multiple resolutions, generates thumbnails, and notifies users when processing is complete.

Chunked Upload

Step 1: Chunked Upload

Client splits video into chunks (5-10 MB each)
Uploads chunks in parallel (improves speed and reliability)
Each chunk uploaded to S3/GCS with multipart upload API
Resumable: if upload fails, resume from last successful chunk
Upload Service tracks progress in Redis/DB

Step 2: Metadata Creation

Once all chunks uploaded, Upload Service creates metadata record
Metadata: video_id, title, description, tags, creator_id, upload_time, file_size, duration
Stored in relational DB (PostgreSQL/MySQL) with unique video_id
Status: "UPLOADED" (pending transcoding)

Transcoding Workers

Step 3: Transcoding Queue

Upload Service publishes message to Transcoding Queue (SQS/Kafka)
Message contains: video_id, S3 path to original, required resolutions
Queue enables async processing, decoupling upload from transcoding
Allows retry logic, DLQ for failed transcodes

Step 4: Transcoding Workers

Pool of worker instances (EC2, Kubernetes pods) consume from queue
Each worker uses FFmpeg to transcode video
Transcode to multiple resolutions: 4K, 1080p, 720p, 480p, 360p, 144p
Multiple codecs: H.264 (compatibility), H.265/HEVC (efficiency), VP9, AV1 (next-gen)
Generate HLS/DASH manifest files (.m3u8, .mpd)
Split video into segments (10-second chunks)
Upload transcoded segments to S3/CDN origin
Update metadata DB: status = "READY", available_resolutions, CDN URLs

Transcoding Time Estimation: - Real-time transcoding: 1 hour video takes ~1 hour to transcode (1x speed) - With GPU acceleration: 0.1-0.3x speed (1 hour video in 6-18 minutes) - Multiple resolutions in parallel: ~20-30 minutes for all resolutions Worker Pool Size: - 500 hours uploaded/min = 30,000 hours/hour - If each worker handles 1 hour in 30 min (2 videos/hour) - Need: 30,000 / 2 = 15,000 workers minimum - With overhead, retries: ~20,000-30,000 workers in pool - Autoscaling based on queue depth

Thumbnail Generation

Step 5: Thumbnail & Preview Generation

Separate worker pool for thumbnail generation
Extract frames at 1s, 5s, 10s, middle, 75% timestamps
Generate multiple thumbnail sizes (small, medium, large)
Use ML model to select best thumbnail (face detection, contrast, aesthetics)
Generate animated preview (GIF or short silent video loop)
Upload thumbnails to CDN

Step 6: Completion Notification

Once transcoding complete, send notification to creator
Notification Service (SNS, Firebase Cloud Messaging, WebSocket)
Email/push notification: "Your video is live!"
Update video status: "PUBLISHED"
Index video in Elasticsearch for search

sequenceDiagram
    participant Client
    participant UploadService
    participant S3
    participant Queue
    participant TranscodingWorker
    participant MetadataDB
    participant CDN
    participant NotificationService

    Client->>UploadService: 1. Initiate upload (metadata)
    UploadService->>MetadataDB: Create video record (UPLOADED)
    UploadService-->>Client: Upload URL + video_id

    Client->>S3: 2. Upload chunks (multipart)
    S3-->>Client: Chunk confirmation

    Client->>UploadService: 3. Complete upload
    UploadService->>Queue: Publish transcode job
    UploadService-->>Client: Upload complete (processing)

    Queue->>TranscodingWorker: 4. Consume transcode job
    TranscodingWorker->>S3: Download original
    TranscodingWorker->>TranscodingWorker: Transcode (FFmpeg)
Multiple resolutions + codecs
    TranscodingWorker->>S3: Upload transcoded segments
    TranscodingWorker->>CDN: Populate CDN origin
    TranscodingWorker->>MetadataDB: Update status (READY)

    TranscodingWorker->>NotificationService: 5. Trigger notification
    NotificationService->>Client: Video published!

Interview Tip

Discuss failure handling. What if transcoding fails? Use DLQ (Dead Letter Queue) for failed jobs. Retry with exponential backoff. Alert on-call if repeated failures. Store error logs in S3 for debugging. Allow creator to retry manually from dashboard.

5. Video Storage

Video storage is the most expensive component. Requires petabytes of capacity, tiered storage, and global distribution.

Storage Architecture:

Original Videos: Stored in S3/GCS (durable, replicated across AZs). Rarely accessed after transcoding. Can use Glacier/Archive tier.
Transcoded Videos: Stored in S3/GCS standard tier. Hot videos cached at CDN edge. Cold videos fetched from origin on-demand.
CDN Origin: S3/GCS buckets serve as CDN origin. CDN pulls segments on cache miss.
Replication: Multi-region replication for disaster recovery. Cross-region replication (CRR) for low-latency global access.
Lifecycle Policies: Automatically move old/unpopular videos to cold storage after 90 days. Delete original raw files after 1 year (keep only transcoded versions).

Storage Cost Optimization: - S3 Standard: $0.023/GB/month - S3 Infrequent Access: $0.0125/GB/month - S3 Glacier: $0.004/GB/month For 10 PB of storage: - All Standard: 10M GB × $0.023 = $230,000/month - Tiered (50% Standard, 30% IA, 20% Glacier): - 5M × $0.023 + 3M × $0.0125 + 2M × $0.004 - = $115k + $37.5k + $8k = $160.5k/month - Savings: ~30% Actual YouTube: Uses Google Cloud Storage, benefits from Google's infrastructure. Netflix: Uses S3 with heavy caching at CDN (Open Connect).

Storage Organization: /videos/ /{video_id}/ original/ video.mp4 transcoded/ h264/ 4k/ segment_001.ts segment_002.ts ... manifest.m3u8 1080p/ segment_001.ts ... manifest.m3u8 720p/ ... hevc/ ... av1/ ... thumbnails/ thumb_small.jpg thumb_large.jpg preview.gif metadata.json

6. Adaptive Bitrate Streaming

Adaptive bitrate streaming (ABR) dynamically adjusts video quality based on network conditions, ensuring smooth playback without buffering.

HLS/DASH Protocols

HLS (HTTP Live Streaming):

Developed by Apple, widely supported (iOS, Safari, Android, most players)
Uses .m3u8 manifest files (playlist of video segments)
Video split into 6-10 second .ts segments
Master playlist references variant playlists (different resolutions)
Client requests segments over HTTP/HTTPS

DASH (Dynamic Adaptive Streaming over HTTP):

Industry standard, codec-agnostic
Uses .mpd manifest files (Media Presentation Description)
Similar segment-based approach
More flexible than HLS, but less universal support

HLS Master Playlist (master.m3u8): #EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=7680000,RESOLUTION=3840x2160 4k/playlist.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=5120000,RESOLUTION=1920x1080 1080p/playlist.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2560000,RESOLUTION=1280x720 720p/playlist.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1280000,RESOLUTION=854x480 480p/playlist.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=640000,RESOLUTION=640x360 360p/playlist.m3u8 Variant Playlist (1080p/playlist.m3u8): #EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXTINF:10.0, segment_001.ts #EXTINF:10.0, segment_002.ts #EXTINF:10.0, segment_003.ts ... #EXT-X-ENDLIST

Quality Switching Logic

Client-Side ABR Algorithm:

Bandwidth Estimation: Client measures download speed of each segment
Buffer Level: Maintains 10-30 seconds of buffer
Switching Logic:
- If buffer < 10s: switch to lower quality (avoid rebuffering)
- If buffer > 30s and bandwidth high: switch to higher quality
- Conservative switching: avoid oscillating between qualities
Startup Quality: Start at low quality (360p/480p), then upgrade
Network Type: Default to lower quality on mobile networks

sequenceDiagram
    participant Client
    participant Player
    participant CDN
    participant OriginServer

    Client->>Player: 1. Request video (video_id)
    Player->>CDN: 2. Request master.m3u8
    CDN-->>Player: Master playlist (all resolutions)

    Player->>Player: 3. Measure bandwidth
Check buffer
    Player->>Player: Select quality (720p)

    Player->>CDN: 4. Request 720p/playlist.m3u8
    CDN-->>Player: Variant playlist (segments)

    Player->>CDN: 5. Request segment_001.ts
    CDN->>CDN: Check cache
    alt Cache HIT
        CDN-->>Player: Segment (from cache)
    else Cache MISS
        CDN->>OriginServer: Fetch segment
        OriginServer-->>CDN: Segment data
        CDN->>CDN: Cache segment
        CDN-->>Player: Segment data
    end

    Player->>Player: 6. Decode & play segment
Update buffer
    Player->>Player: Measure download speed
Check buffer level

    alt Low bandwidth detected
        Player->>Player: Switch to 480p
        Player->>CDN: Request 480p/segment_002.ts
    else High bandwidth & buffer healthy
        Player->>Player: Switch to 1080p
        Player->>CDN: Request 1080p/segment_002.ts
    end

    Player->>CDN: Continue fetching segments...

Interview Tip

Discuss segment size tradeoffs. Smaller segments (2-4s): faster quality switching, more overhead. Larger segments (10-15s): less overhead, slower switching. YouTube uses 5-10s segments. Netflix uses 2-4s for faster adaptation. Ask interviewer about latency vs efficiency priorities.

7. Video Serving & Playback

Serving billions of video streams requires a multi-tier CDN architecture with intelligent routing and caching.

CDN Architecture:

Edge Locations: Thousands of edge servers globally (Cloudflare, Akamai, Fastly). Serve 90%+ of requests from cache.
Regional Caches: Mid-tier caches between edge and origin. Cache less popular content.
Origin Servers: S3/GCS buckets. Only hit on cache miss.
DNS-Based Routing: GeoDNS routes users to nearest edge location.
Anycast: Multiple servers share same IP, routed to closest one.
Cache Hierarchy: Edge -> Regional -> Origin. Each tier has larger capacity but higher latency.

Playback Optimization Techniques:

Pre-buffering: Fetch first 2-3 segments immediately (20-30s of video). Start playback within 1-2s.
Seek Optimization: Use keyframe index to seek without downloading entire video. For seek to 5:30, fetch segment covering that timestamp.
Range Requests: HTTP 206 Partial Content allows requesting byte ranges. Useful for seeking.
Connection Reuse: Keep HTTP/2 connection open for multiple segment requests (multiplexing).
Prefetching: Predict next segment, fetch before needed. Reduce latency.
Quality Presets: Allow user to lock quality (disable ABR). Useful for data-conscious users.

CDN Cache Hit Rate Impact: Assumptions: - 1B hours watched/day = 360M segment requests/second (10s segments) - Origin bandwidth cost: $0.08/GB - CDN bandwidth cost: $0.02/GB (cached) + origin cost for misses Without CDN (100% origin): - 900 TB/day × $0.08/GB = $72,000/day = $2.16M/month With CDN (95% cache hit rate): - Cached: 855 TB × $0.02 = $17,100/day - Origin: 45 TB × $0.08 = $3,600/day - Total: $20,700/day = $621k/month - Savings: 71% With CDN (99% cache hit rate): - Cached: 891 TB × $0.02 = $17,820/day - Origin: 9 TB × $0.08 = $720/day - Total: $18,540/day = $556k/month - Savings: 74% Key takeaway: CDN is essential, not optional. Improves cost AND latency.

Interview Tip

Discuss Netflix's Open Connect. Netflix built its own CDN (Open Connect Appliances) deployed at ISP locations. Free for ISPs (reduces their transit costs), benefits Netflix (lower latency, higher control). Mention as alternative to third-party CDNs for massive scale.

8. Search & Discovery

Users search for videos by title, tags, creator, description. Requires full-text search with ranking and filtering.

Search Architecture:

Elasticsearch: Distributed search engine, full-text indexing, fast fuzzy search
Indexing Pipeline: When video published, metadata indexed in Elasticsearch
Search Index Fields: title, description, tags, creator_name, category, upload_date, view_count, like_ratio
Ranking Signals:
- Relevance score (BM25 algorithm)
- Recency boost (newer videos ranked higher)
- Popularity boost (view count, engagement rate)
- Creator authority (subscriber count, verified status)
- User personalization (watch history, preferences)
Auto-Complete: Prefix search on popular queries (cached in Redis)
Query Expansion: Synonyms, spelling correction

Elasticsearch Document Schema: { "video_id": "abc123", "title": "How to Design YouTube | System Design Interview", "description": "Complete guide to designing a video streaming platform...", "tags": ["system design", "interview", "youtube", "architecture"], "creator_id": "user456", "creator_name": "System Design Channel", "creator_subscribers": 500000, "upload_date": "2026-05-10T14:30:00Z", "duration_seconds": 1800, "view_count": 125000, "like_count": 8500, "comment_count": 320, "category": "Education", "language": "en", "thumbnails": { "small": "https://cdn.example.com/thumb_small.jpg", "large": "https://cdn.example.com/thumb_large.jpg" }, "engagement_rate": 0.068, // (likes + comments) / views "freshness_score": 0.95 // decay over time }

Trending Algorithm:

Identifies videos with rapid growth in views/engagement
Formula: Score = (Views * EngagementRate) / (Age in hours + 2)^1.5
Penalizes older videos (time decay)
Rewards engagement (likes, comments, shares)
Updated every 15 minutes (batch job)
Cached in Redis, served to homepage/trending page

Interview Tip

Mention eventual consistency. View counts and engagement metrics don't need real-time accuracy. Batch update Elasticsearch every 5-15 minutes. This reduces write load and allows caching. Discuss tradeoff: stale data vs system load.

9. Recommendation System

Recommendations are critical for engagement. YouTube: 70%+ of watch time from recommendations. Netflix: 80%+ from recommendations.

Recommendation Approaches:

Collaborative Filtering: Users who watched A also watched B. Matrix factorization, user-user similarity.
Content-Based Filtering: Recommend videos similar to what user watched. Use video metadata, tags, categories.
Deep Learning Models: Neural networks trained on billions of interactions. YouTube uses deep neural networks (DNN) with user features, video features, context features.
Hybrid Approach: Combine multiple signals. Ensemble of models.

graph TB
    subgraph "Data Collection"
        UserActions[User Actions
Watch, Like, Comment, Share]
        VideoFeatures[Video Features
Metadata, Tags, Category]
        ContextData[Context
Time, Device, Location]
    end

    subgraph "Feature Engineering"
        UserProfile[User Profile
Watch History, Preferences]
        VideoEmbeddings[Video Embeddings
Content Vectors]
        ContextFeatures[Context Features
Time of day, Device type]
    end

    subgraph "ML Pipeline"
        CandidateGeneration[Candidate Generation
Retrieve ~1000 candidates]
        Ranking[Ranking Model
Score & rank top 50]
        Reranking[Re-ranking
Diversity, Freshness]
    end

    subgraph "Serving Layer"
        OnlineInference[Online Inference
Real-time scoring]
        Cache[Redis Cache
Pre-computed recs]
        ABTest[A/B Testing
Model variants]
    end

    UserActions --> UserProfile
    VideoFeatures --> VideoEmbeddings
    ContextData --> ContextFeatures

    UserProfile --> CandidateGeneration
    VideoEmbeddings --> CandidateGeneration
    ContextFeatures --> Ranking

    CandidateGeneration --> Ranking
    Ranking --> Reranking
    Reranking --> OnlineInference
    OnlineInference --> Cache
    Cache --> ABTest

    style CandidateGeneration fill:#4caf50,color:#fff
    style Ranking fill:#ff9800,color:#fff
    style ABTest fill:#2196f3,color:#fff

Two-Stage Recommendation Pipeline:

Stage 1: Candidate Generation
- Goal: Retrieve ~1000-2000 candidate videos from millions/billions
- Use fast retrieval methods: collaborative filtering, nearest neighbor search
- Sources: watched video similarity, user-user similarity, trending, subscriptions
- Low precision OK, high recall needed (don't miss good videos)
Stage 2: Ranking
- Goal: Score and rank candidates, select top 50 for display
- Use expensive deep learning models (DNN with 100+ features)
- Features: user history, video metadata, engagement signals, context
- Predict: probability of watch, watch time, engagement
- Objective: Maximize expected watch time (business metric)
Stage 3: Re-ranking
- Apply business rules: diversity (not all from same creator), freshness (mix old/new), policy (no harmful content)
- A/B testing: show different variants to different users

Recommendation Serving Infrastructure: Online Inference: - 1B DAU × 50 recommendations/day = 50B predictions/day - = 578,000 predictions/second (peak: 1-2M/sec) Latency requirement: < 100ms for recommendations Solution: - Pre-compute recommendations for active users (cache in Redis) - Refresh cache every 1-6 hours - For cold start / cache miss: real-time inference with GPU serving - Use model serving frameworks: TensorFlow Serving, TorchServe Model size: - DNN with 100M-1B parameters - Need GPU instances for inference (P3, V100, A100) - Batch inference for cache refresh - Real-time inference for personalization Cost optimization: - Cache recommendations for 80% of users (pre-compute) - Real-time inference only for 20% (cache miss, cold start)

Interview Tip

Discuss feedback loops. Recommendations affect what users watch, which affects future recommendations (echo chamber risk). Mention exploration-exploitation tradeoff: 80% exploit (show high-confidence recs), 20% explore (show diverse/new content). Prevents filter bubbles, improves long-term engagement.

10. Database Design

Multiple databases for different access patterns: relational for metadata, NoSQL for high-throughput writes, cache for read-heavy data.

Video Metadata (PostgreSQL/MySQL - Relational) Table: videos ----------------------------------------------- video_id VARCHAR(20) PRIMARY KEY creator_id VARCHAR(20) NOT NULL title VARCHAR(200) NOT NULL description TEXT upload_time TIMESTAMP NOT NULL duration_seconds INT NOT NULL status ENUM('UPLOADED','PROCESSING','READY','FAILED') NOT NULL category VARCHAR(50) language VARCHAR(10) view_count BIGINT DEFAULT 0 like_count INT DEFAULT 0 dislike_count INT DEFAULT 0 comment_count INT DEFAULT 0 created_at TIMESTAMP DEFAULT NOW() updated_at TIMESTAMP DEFAULT NOW() INDEX idx_creator_id (creator_id) INDEX idx_upload_time (upload_time) INDEX idx_status (status) INDEX idx_category_upload (category, upload_time) Table: video_files ----------------------------------------------- file_id BIGINT PRIMARY KEY AUTO_INCREMENT video_id VARCHAR(20) NOT NULL resolution VARCHAR(10) NOT NULL -- '4k', '1080p', '720p', etc. codec VARCHAR(20) NOT NULL -- 'h264', 'hevc', 'av1' file_path VARCHAR(500) NOT NULL file_size_bytes BIGINT NOT NULL segment_count INT NOT NULL manifest_url VARCHAR(500) NOT NULL created_at TIMESTAMP DEFAULT NOW() FOREIGN KEY (video_id) REFERENCES videos(video_id) INDEX idx_video_id (video_id) Table: users ----------------------------------------------- user_id VARCHAR(20) PRIMARY KEY username VARCHAR(50) NOT NULL UNIQUE email VARCHAR(100) NOT NULL UNIQUE created_at TIMESTAMP DEFAULT NOW() subscriber_count INT DEFAULT 0 verified BOOLEAN DEFAULT FALSE Table: subscriptions ----------------------------------------------- subscription_id BIGINT PRIMARY KEY AUTO_INCREMENT subscriber_id VARCHAR(20) NOT NULL creator_id VARCHAR(20) NOT NULL subscribed_at TIMESTAMP DEFAULT NOW() FOREIGN KEY (subscriber_id) REFERENCES users(user_id) FOREIGN KEY (creator_id) REFERENCES users(user_id) UNIQUE KEY unique_subscription (subscriber_id, creator_id) INDEX idx_subscriber (subscriber_id) INDEX idx_creator (creator_id) Table: comments ----------------------------------------------- comment_id BIGINT PRIMARY KEY AUTO_INCREMENT video_id VARCHAR(20) NOT NULL user_id VARCHAR(20) NOT NULL parent_comment_id BIGINT NULL -- for threaded replies comment_text TEXT NOT NULL like_count INT DEFAULT 0 created_at TIMESTAMP DEFAULT NOW() FOREIGN KEY (video_id) REFERENCES videos(video_id) FOREIGN KEY (user_id) REFERENCES users(user_id) INDEX idx_video_id (video_id, created_at) INDEX idx_user_id (user_id)

User Interactions (Cassandra/DynamoDB - NoSQL for high write throughput) Table: video_views (Cassandra) ----------------------------------------------- Partition Key: video_id Clustering Key: view_time (descending) Columns: - video_id (text) - user_id (text) - view_time (timestamp) - watch_duration_seconds (int) - quality (text) -- resolution watched - device_type (text) - geo_location (text) Purpose: Track every view for analytics. High write volume. Query patterns: Get views for video in time range, get user watch history. Table: user_watch_history (Cassandra) ----------------------------------------------- Partition Key: user_id Clustering Key: watch_time (descending) Columns: - user_id (text) - video_id (text) - watch_time (timestamp) - watch_duration_seconds (int) - completed (boolean) Purpose: User's watch history for recommendations. Query pattern: Get recent watch history for user (for recommendations). Table: video_likes ----------------------------------------------- Partition Key: video_id Clustering Key: user_id Columns: - video_id (text) - user_id (text) - liked_at (timestamp) Purpose: Track likes. Prevent duplicate likes (unique user_id per video_id).

Database Sharding Strategy:

Video Metadata: Shard by video_id hash. Distribute videos evenly across shards.
User Data: Shard by user_id hash. Keep user's data co-located.
Views/Interactions: Use Cassandra with video_id or user_id as partition key. Auto-sharded by Cassandra.
Read Replicas: Multiple read replicas for video metadata (read-heavy). Write to master, read from replicas.
Caching Layer: Redis for hot data (popular video metadata, user sessions, trending videos). Cache-aside pattern.

Interview Tip

Discuss eventual consistency tradeoff. View counts don't need to be exact in real-time. Batch update from Cassandra to PostgreSQL every 5-15 minutes. Reduces write load on relational DB. Users won't notice 10-minute lag in view count. Prioritize write throughput over read consistency for counters.

11. Scalability & Fault Tolerance

System must scale to billions of users, handle failures gracefully, and maintain high availability.

Scalability Techniques:

Horizontal Scaling: All services are stateless, scale by adding more instances. Use auto-scaling groups (ASG) based on CPU/memory/queue depth.
Multi-Region Deployment: Deploy in multiple AWS regions (us-east-1, eu-west-1, ap-southeast-1). Route users to nearest region (latency-based routing).
CDN Multi-Tier: Edge -> Regional -> Origin. 99%+ cache hit rate at edge. Reduces origin load.
Database Sharding: Partition data across multiple DB instances. Video metadata sharded by video_id. User data sharded by user_id.
Queue-Based Decoupling: Upload and transcoding decoupled via SQS/Kafka. Allows independent scaling of upload and transcoding services.
Transcoding Farm Autoscaling: Scale worker pool based on queue depth. Add workers during peak upload times, remove during off-peak.

Fault Tolerance & Reliability:

Redundancy: Multi-AZ deployment for all services. If one AZ fails, traffic routes to healthy AZs.
Data Replication: S3/GCS automatically replicates data across multiple data centers. Cross-region replication (CRR) for disaster recovery.
Graceful Degradation: If recommendation service fails, fall back to trending/popular videos. If search fails, show cached results.
Circuit Breaker: If downstream service (e.g., recommendation API) has high latency/errors, open circuit breaker, serve cached/default results.
Rate Limiting: Protect services from overload. Limit requests per user, per IP. Use token bucket algorithm.
DDoS Protection: Cloudflare/AWS Shield for DDoS mitigation. Rate limiting at edge.
Health Checks: Load balancer pings /health endpoint. Remove unhealthy instances from rotation.
Dead Letter Queue (DLQ): Failed transcoding jobs sent to DLQ. Alert on-call, retry manually or automatically.

Disaster Recovery Strategy:

RTO (Recovery Time Objective): 1 hour for streaming, 4 hours for uploads
RPO (Recovery Point Objective): 5 minutes (max data loss acceptable)
Backup: S3 versioning enabled. Cross-region replication. DB snapshots every 6 hours + continuous replication to standby.
Failover: Automated DNS failover to backup region if primary region unavailable. Use Route53 health checks.
Testing: Quarterly disaster recovery drills. Simulate region failure, validate failover.

Example: Transcoding Farm Autoscaling Autoscaling policy: - Target metric: SQS queue depth - Scale up: If queue depth > 10,000 for 5 minutes, add 1000 workers - Scale down: If queue depth < 2,000 for 15 minutes, remove 500 workers - Min workers: 5,000 (baseline) - Max workers: 50,000 (peak) Peak upload time: 6pm-10pm local time (staggered globally) - Queue depth spikes to 50,000 jobs - Autoscaling adds workers: 5k -> 15k -> 25k -> 35k (over 30 min) - Queue processed faster, depth drops - Off-peak: 2am-6am, queue depth < 2,000 - Autoscaling removes workers: 35k -> 25k -> 15k -> 10k (over 2 hours) Cost savings: Pay only for workers needed. Off-peak cost reduced by 60-70%.

Interview Tip

Discuss monitoring & alerting. Use CloudWatch/Datadog/Prometheus for metrics. Alert on: high error rate, high latency, queue depth spike, CDN cache hit rate drop, transcoding failures. Set up on-call rotation. Incident response playbook for common failures.

12. Tradeoffs & Alternatives

System design involves tradeoffs. Discuss alternatives and justify decisions based on requirements.

Decision Point	Option A	Option B	Chosen & Rationale
Upload Completion Notification	Push: Server pushes notification (WebSocket, FCM)	Pull: Client polls status endpoint every 10s	Push (WebSocket/FCM). Lower latency, better UX. Polling wastes bandwidth for long transcoding jobs (20-30 min). Push reduces server load (no repeated polling).
Recommendation Generation	Pre-computed: Batch compute recommendations, cache in Redis	On-the-fly: Compute recommendations in real-time per request	Pre-computed for 80%, on-the-fly for 20%. Hybrid approach. Pre-compute for active users (lower latency, cost-efficient). Real-time for cold start/cache miss (better personalization). Refresh cache every 1-6 hours.
Video Transcoding	Synchronous: Transcode during upload, block until complete	Asynchronous: Queue-based, transcode in background	Asynchronous (queue-based). Upload and transcoding decoupled. Avoids blocking user. Allows retry on failure. Enables autoscaling of transcoding workers independently.
CDN Strategy	Third-party CDN: Cloudflare, Akamai, Fastly	Custom CDN: Build own edge network (like Netflix Open Connect)	Third-party CDN for most use cases. Faster time-to-market, lower upfront cost, global coverage. Custom CDN (Open Connect) for Netflix scale. Better control, lower long-term cost, optimized for video streaming. Tradeoff: build vs buy.
Segment Size (HLS/DASH)	Small (2-4s): Faster quality switching, lower latency	Large (10-15s): Less overhead, fewer HTTP requests	Medium (6-10s) for YouTube. Balance between switching speed and overhead. Small (2-4s) for Netflix. Faster adaptation critical for varying network conditions. Depends on use case: live streaming needs smaller segments.
View Count Consistency	Strong consistency: Real-time view count updates	Eventual consistency: Batch update view counts every 5-15 min	Eventual consistency. Users don't need exact real-time view counts. 10-minute lag acceptable. Reduces write load on database (billions of views/day). Batch updates more efficient.
Transcoding Codec Priority	H.264 (widely compatible): Works on all devices	AV1 (efficient): 30% smaller files, lower bandwidth	Multi-codec approach. Transcode to H.264 (baseline), H.265/HEVC (modern devices), AV1 (cutting-edge). Client selects best codec supported. Tradeoff: higher storage/transcoding cost vs lower bandwidth cost. YouTube/Netflix prioritize bandwidth savings (AV1).
Metadata Database	Relational (PostgreSQL/MySQL): ACID, complex queries	NoSQL (DynamoDB/Cassandra): High throughput, horizontal scaling	Relational for video metadata (complex queries, joins). NoSQL for interactions (views, likes - high write throughput). Polyglot persistence: use right DB for each use case.

Interview Tip

Always justify tradeoffs with requirements. Don't just pick a technology because it's popular. E.g., "We chose eventual consistency for view counts because the non-functional requirement prioritizes low latency and high throughput over real-time accuracy, and users don't notice 10-minute lag in view counts." Tie decisions back to requirements.

Additional Alternatives to Discuss:

Live Streaming: Requires different architecture. Use RTMP ingest, low-latency HLS (LL-HLS) or WebRTC for sub-second latency. More complex than VOD.
Content Moderation: ML models for detecting inappropriate content. Pre-moderation (before publish) vs post-moderation (after publish). User reporting system.
DRM (Digital Rights Management): Encrypt videos, issue licenses for playback. Required for premium content (Netflix). Adds complexity to player and key management.
Ad Insertion: Server-side ad insertion (SSAI) vs client-side. SSAI harder to block but more complex. Pre-roll, mid-roll, post-roll ads.
Monetization: Ad revenue sharing with creators. Subscription tiers (ad-free). Pay-per-view. Affects recommendation algorithm (optimize for engagement vs revenue).
Copyright Detection: Content ID system (YouTube). Fingerprint videos, detect re-uploads. Complex ML + legal workflows.

Conclusion

Designing a video streaming platform like YouTube or Netflix is a massive undertaking involving:

Upload Pipeline: Chunked upload, transcoding to multiple resolutions/codecs, thumbnail generation, async processing via queues
Storage: Petabytes of video data, tiered storage (hot/cold), multi-region replication, CDN origin
Adaptive Streaming:HLS/DASH protocols, segment-based delivery, client-side quality switching based on bandwidth/buffer
CDN: Multi-tier caching (edge -> regional -> origin), 95%+ cache hit rate, global distribution for low latency
Search & Discovery: Elasticsearch for full-text search, trending algorithm, ranking by relevance + popularity + recency
Recommendations: Two-stage pipeline (candidate generation + ranking), deep learning models, pre-computed + real-time inference
Scalability: Horizontal scaling, multi-region deployment, queue-based decoupling, autoscaling transcoding farm
Fault Tolerance: Multi-AZ deployment, data replication, graceful degradation, circuit breakers, DLQ for failed jobs

Final Interview Tips

1. Clarify scope early. Video platforms are too broad. Focus on 2-3 subsystems (e.g., upload + streaming, or recommendations + search).

2. Start with requirements, then scale numbers. Requirements drive design. Capacity estimation shows you understand scale.

3. Draw diagrams. Architecture diagram, sequence diagrams (upload flow, streaming flow). Visuals help interviewer follow.

4. Discuss tradeoffs. No perfect solution. Every decision has pros/cons. Justify choices based on requirements.

5. Mention real-world examples. YouTube's architecture (Google infrastructure, Vitess for MySQL sharding), Netflix Open Connect, AWS MediaConvert. Shows you've researched beyond theory.

6. Deep dive where asked. If interviewer says "tell me more about transcoding," go deep. If they move on, don't over-explain.

7. Think beyond happy path. Discuss failures: what if transcoding fails? What if DB goes down? How do we handle spikes? What if CDN cache hit rate drops?

Further Reading:

YouTube Architecture (InfoQ): Multi-datacenter, serving 1B+ hours/day
Netflix Tech Blog: Open Connect CDN, encoding pipeline, recommendation systems
HLS/DASH Specifications: Apple HLS RFC 8216, DASH ISO/IEC 23009
Video Encoding Guide: FFmpeg documentation, x264/x265/AV1 codec comparison
Recommendation Systems: Collaborative Filtering, Matrix Factorization, Deep Learning for Recommendations
AWS MediaConvert, MediaLive: Managed services for video transcoding and live streaming

This chapter covered the full lifecycle of a video streaming platform, from upload to serving to recommendations. In an interview, adapt depth based on time and interviewer focus. Aim for breadth first, then deep dive into 1-2 areas.

Operational Readiness (Production-Grade)

A high-level design is incomplete without operational readiness. Here's what makes this YouTube design production-grade:

SLIs/SLOs (Service Level Indicators/Objectives)

Video start latency: P99 < 2 seconds (time from click to first frame)
Upload success rate: > 99.5% (uploads complete successfully without errors)
Transcode completion: P99 < 30 minutes (time from upload complete to video ready)
CDN availability: 99.99% uptime (4 nines)
Search latency: P95 < 200ms
Recommendation latency: P95 < 100ms

Monitoring

Prometheus + Grafana Dashboards:

Upload QPS: Track upload rate, alert if drops below expected (may indicate upload service down)
Transcode queue depth: Monitor backlog, autoscale workers if depth > 10K for 5 minutes
CDN hit rate: Track cache hit percentage (target: 95%+). Drop indicates cache invalidation issue or traffic pattern change
Error rates per service: Track 4xx (client errors) and 5xx (server errors) separately. Alert if 5xx rate > 0.1%
Video playback starts: Track successful playback starts vs failures. Alert if failure rate > 1%
Database metrics: Connection pool utilization, query latency, replication lag

Alerting

Page immediately: Transcode failure rate > 5% for 10 minutes (indicates systemic issue, not isolated failures)
Page immediately: Upload service error rate > 1% (users cannot upload videos)
Warn (no page): CDN cache hit rate < 90% (investigate during business hours, not urgent)
Warn (no page): Transcode queue depth > 50K (may need to scale workers, not immediate emergency)
Page immediately: Video playback error rate > 2% (users cannot watch videos)

Alerting Philosophy: Alert on symptoms (users affected), not causes (CPU high). CDN hit rate drop is a symptom. Page if it impacts user experience (playback latency > SLO), warn if it's just a cost concern.

Deployment

Canary Rollout Strategy:

Stage 1: Deploy to 5% of traffic (1 server in 20-server fleet)
Observe: Monitor error rates, latency, CPU for 15 minutes
Stage 2: If metrics healthy, expand to 25% of traffic
Observe: Monitor for 30 minutes
Stage 3: Expand to 100% if no issues detected
Rollback: Automated rollback if error rate spikes > 2x baseline at any stage

Circuit Breakers

Transcoding Service → Upstream Storage: If S3 upload failures > 10% for 30 seconds, open circuit, queue transcoded segments locally, retry after 60 seconds
Recommendation Service → ML Model Serving: If ML service latency > 500ms (P50), open circuit, fall back to trending videos for 2 minutes
Search Service → Elasticsearch: If ES errors > 5%, open circuit, serve cached search results (stale but available)

Disaster Recovery

Multi-Region CDN: - CDN edge locations in 100+ countries (Cloudflare, Akamai) - Automatic failover: if edge location down, DNS routes to next nearest edge (transparent to users) - No RPO/RTO for CDN (stateless, instant failover) Video Metadata (PostgreSQL): - Primary: us-east-1, Standby: us-west-2, eu-west-1 - Continuous replication (streaming replication, <5 second lag) - RPO: 5 minutes (max data loss if primary region destroyed) - RTO: 15 minutes (time to promote standby to primary, update DNS) Video Storage (S3): - Cross-region replication (CRR) enabled - Replicate to 3 regions: us-east-1, us-west-2, eu-west-1 - RPO: 15 minutes (S3 CRR is asynchronous) - RTO: 0 minutes (CDN can pull from any region, automatic failover) DR Drill: - Quarterly drill: simulate us-east-1 region outage - Test: promote us-west-2 to primary, verify CDN routes to backup region, confirm uploads work - Post-drill: document gaps, improve runbooks

Testing

Load testing: Run at 2x peak traffic quarterly. Simulate 40,000 uploads/sec, 400K playback starts/sec. Verify autoscaling works, no cascading failures
Chaos testing: Kill random transcoding workers weekly (automated via Chaos Monkey). Verify: jobs retry, no user impact, queue drains normally
Integration tests: End-to-end upload pipeline test runs every deploy. Upload test video → verify transcoding completes → verify video playable → verify thumbnails generated
Canary uploads: Synthetic uploads every 5 minutes to each region. Alert if canary upload fails (detects upload service down before users report it)

Interview Tip

Don't skip operational readiness. Many candidates design beautiful architectures but forget monitoring, alerting, DR. Mentioning "we'll use Prometheus for monitoring" shows you've thought about operations. Mentioning specific SLOs (P99 < 2s video start latency) shows you understand user experience metrics. Mentioning chaos testing shows you understand production maturity.