Netflix – Streaming Service

0) Problem Restatement

Design a video streaming platform like Netflix where users can browse content, watch videos with adaptive quality, get personalized recommendations, and enjoy seamless playback across devices. The core challenges are efficient video delivery at scale, handling millions of concurrent streams, adaptive bitrate streaming, and building a recommendation engine.

1) Requirements

1.1 Functional

• Browse catalog (movies, TV shows, categories).
• Search content by title, genre, actors.
• Watch videos with play, pause, seek, resume functionality.
• Adaptive bitrate streaming (adjust quality based on bandwidth).
• Personalized recommendations and trending content.
• User profiles with watch history and preferences.
• Download for offline viewing (mobile).
• Subtitles and multiple audio tracks.
• Continue watching from last position across devices.

1.2 Non-Functional

• Scalability: Support 200M+ users, ~20M peak concurrent streams.
• Low Latency: Video start time < 2 seconds, buffering < 1%.
• High Availability: 99.99% uptime for streaming.
• Global Reach: Low latency worldwide via CDN.
• Quality: Adaptive bitrate streaming (360p to 4K).
• Storage: Petabytes of video content.
• Cost Efficiency: Optimize CDN and storage costs.

1.3 Scale Estimates

• Users: 200M subscribers, 100M daily active users.
• Content: 10K movies + 5K TV series = ~50K hours of video.
• Watch time: 100M DAU × ~2 hours/day = 200M hours/day (~6B hours/month).
• Concurrent streams: 200M hours/day ÷ 24 ≈ 8M average; evening peaks run ~2–3× average → ~20M peak concurrent streams.
• Bandwidth:
• Avg bitrate: 5 Mbps (1080p).
• Peak traffic: 20M streams × 5 Mbps = 100 Tbps (terabits/sec). No origin can serve this — it has to come from caches close to users (Deep Dive B).
• Storage:
• Per hour of content: ~10 renditions (resolutions × codecs) × ~5 GB ≈ 50 GB.
• Total: 50K hours × 50 GB ≈ 2.5 PB, before replication. Small next to the bandwidth problem.

1.4) API Specifications

Content Discovery APIs

• GET /api/browse - Get content catalog with categories (Trending, New Releases, etc.)
• GET /api/search - Search content by title, genre, actors, or keywords
• GET /api/recommendations/{profile_id} - Get personalized recommendations for user profile
• GET /api/content/{video_id} - Get detailed content metadata (title, description, cast, ratings)
• GET /api/genres - List all available genres and categories

Video Playback APIs

• GET /api/play/{video_id} - Get video manifest file (HLS .m3u8 or DASH .mpd) with CDN URLs
• POST /api/playback/progress - Update watch progress for resume functionality
• GET /api/playback/resume/{profile_id} - Get watch history and resume positions

Content Upload APIs (Internal/Partner)

• POST /api/upload/initiate - Initiate video upload session
• POST /api/upload/complete - Mark upload as complete and trigger encoding
• GET /api/encoding/status/{job_id} - Check encoding job status

Analytics & Tracking APIs

• POST /api/events - Log user events (play, pause, seek, rate)
• POST /api/ratings - Submit content rating
• GET /api/watch-history/{profile_id} - Get complete watch history

2) High-Level Architecture

2.1 Overview

• Client → API Gateway → Content Service → Video Service → CDN → Recommendation Engine → Analytics.
• Key components: Video encoding pipeline, CDN for delivery, metadata service, recommendation ML models, user preference tracking.

2.2 Architecture Diagram

flowchart TB
    %% User Interactions
    User["User - Web/Mobile/TV"] -->|"1. browse, search"| AG["API Gateway"]
    User -->|"7. video playback request"| AG
    
    %% Metadata & Discovery
    AG -->|"2. GET /browse, /search"| CS["Content Service"]
    CS -->|"3. fetch metadata"| MetaDB[(Metadata DB<br/>Title, Genre, Cast)]
    CS -->|"4. get recommendations"| Rec["Recommendation Engine"]
    Rec -->|"5. ML model inference"| RecDB[(User Preferences DB)]
    Rec -->|"6. return personalized list"| CS
    
    %% Video Playback
    AG -->|"8. GET /play/{videoId}"| VS["Video Service"]
    VS -->|"9. get video manifest (m3u8)"| Storage["Video Storage<br/>(S3)"]
    VS -->|"10. return CDN URLs"| User
    User -->|"11. stream video chunks"| CDN["CDN<br/>(Open Connect caches in ISPs)"]
    CDN -->|"12. fetch on cache miss"| Storage
    
    %% Upload & Encoding Pipeline
    Creator["Content Creator"] -->|"13. upload raw video"| Upload["Upload Service"]
    Upload -->|"14. store raw"| RawStorage["Raw Video Storage<br/>(S3)"]
    Upload -->|"15. trigger encoding job"| Queue["Message Queue<br/>(SQS/Kafka)"]
    Queue -->|"16. consume"| Encoder["Encoding Service<br/>(Transcoding)"]
    Encoder -->|"17. encode multiple formats"| Storage
    Encoder -->|"18. generate thumbnails"| Storage
    Encoder -->|"19. update metadata"| MetaDB
    
    %% User Activity Tracking
    User -->|"20. watch events (play, pause, progress)"| Track["Tracking Service"]
    Track -->|"21. log events"| EventStream["Event Stream<br/>(Kafka)"]
    EventStream -->|"22. consume"| Analytics["Analytics Service"]
    Analytics -->|"23. update watch history"| RecDB
    Analytics -->|"24. aggregate metrics"| DataWarehouse[(Data Warehouse<br/>Redshift)]
    
    %% Recommendation Training
    DataWarehouse -.->|"train ML models"| MLTrain["ML Training Pipeline"]
    MLTrain -.->|"deploy models"| Rec
    
    %% Styling
    classDef user fill:#e3f2fd,stroke:#1976d2,stroke-width:2px;
    classDef core fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    classDef storage fill:#fff9c4,stroke:#f57f17,stroke-width:2px;
    classDef ml fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
    classDef cdn fill:#ffe0b2,stroke:#e65100,stroke-width:2px;
    
    class User,Creator user;
    class AG,CS,VS,Upload,Track core;
    class MetaDB,Storage,RawStorage,RecDB,DataWarehouse storage;
    class Rec,MLTrain,Analytics ml;
    class CDN,Queue,EventStream cdn;

3) Components (what & why)

Client (Web/Mobile/TV Apps)

• Video Player: HTML5 player (web) or native player (iOS, Android, Smart TV).
• Adaptive Bitrate Streaming: Automatically switch quality based on bandwidth.
• Offline Download: Cache videos locally for offline playback.
• UI: Browse catalog, search, watch history, recommendations.

API Gateway

• Authentication (JWT tokens), authorization, rate limiting.
• Routes requests to appropriate microservices.
• SSL termination and DDoS protection.

Content Service

• Responsibilities:
• Serve content catalog (browse, search).
• Return metadata: title, description, genre, cast, thumbnails.
• Integrate with Recommendation Engine for personalized feeds.
• Optimization: Cache popular metadata in Redis.

Video Service

• Responsibilities:
• Handle video playback requests.
• Return manifest file (e.g., HLS .m3u8, DASH .mpd) with CDN URLs.
• Track playback progress for resume functionality.
• Manifest File: Contains URLs to video segments at different bitrates.

CDN (Content Delivery Network)

• Purpose: Deliver video content with low latency globally.
• Providers: Netflix runs its own CDN, Open Connect (cache servers placed inside ISP networks). A smaller service would use a commercial CDN (CloudFront, Akamai, Fastly).
• Strategy:
• Cache video segments at edge locations near users.
• Origin: S3 or object storage.
• Cache popular content (80/20 rule: 20% content = 80% views).
• Optimization: Pre-warm cache for new releases.

Video Storage (S3/Object Storage)

• Store encoded video files in multiple formats and resolutions.
• Structure: /videos/{videoId}/{quality}/{chunk-001.ts}
• Redundancy: Multi-region replication for disaster recovery.

Upload Service

• Responsibilities:
• Accept raw video uploads from content creators.
• Store raw files in S3.
• Trigger encoding pipeline.
• Validation: Check file format, size, and codec.

Encoding Service (Transcoding)

• Responsibilities:
• Convert raw video to multiple formats and resolutions.
• Generate thumbnails and preview clips.
• Create manifest files (HLS/DASH).
• Output Formats: 360p, 480p, 720p, 1080p, 4K.
• Codecs: H.264, H.265 (HEVC), AV1 (newer, more efficient).
• Tools: FFmpeg, AWS MediaConvert, or custom solution.
• Parallelization: Split video into chunks, encode in parallel.

Recommendation Engine

• Responsibilities:
• Generate personalized recommendations.
• Rank content by user preferences.
• Power "Trending", "Top Picks", "Because You Watched" sections.
• ML Models: Collaborative filtering, content-based filtering, hybrid models.
• Inputs: Watch history, ratings, search queries, time spent.
• Real-Time: Low-latency model serving (ML inference API).

Tracking Service

• Responsibilities:
• Log user events: play, pause, seek, completion, ratings.
• Update watch progress for resume functionality.
• Event Stream: Kafka or Kinesis for high-throughput event ingestion.

Analytics Service

• Responsibilities:
• Aggregate watch metrics (views, watch time, completion rate).
• Feed data to recommendation system.
• Business intelligence (popular content, user retention).
• Storage: Data warehouse (Redshift, BigQuery, Snowflake).

Metadata DB

• Store content metadata: titles, descriptions, genres, cast, release dates.
• DB Choice: PostgreSQL or DynamoDB (fast reads).

User Preferences DB

• Store user watch history, ratings, preferences, profiles.
• DB Choice: Cassandra or DynamoDB (high write throughput).

4) Data Model

Video

Video(
  video_id, 
  title, 
  description, 
  genre[], 
  cast[], 
  duration_seconds, 
  release_date, 
  thumbnail_url,
  manifest_url,  -- HLS/DASH manifest
  upload_date
)

Video File (Encoded)

VideoFile(
  file_id,
  video_id,
  resolution,  -- 360p, 720p, 1080p, 4K
  bitrate_kbps,
  codec,  -- H.264, H.265, AV1
  storage_url  -- S3 path
)

User

User(user_id, email, subscription_plan, created_at)

Profile

Profile(profile_id, user_id, name, avatar, preferences[])

Watch History

WatchHistory(
  history_id,
  profile_id,
  video_id,
  watch_position_seconds,  -- for resume
  completed,
  watched_at
)

Rating

Rating(rating_id, profile_id, video_id, rating, created_at)

5) Key Flows

5.1 Browse & Search Flow

1. User opens app → Client fetches content catalog from Content Service.
2. Content Service queries Metadata DB (with Redis cache).
3. Recommendation Engine returns personalized feed.
4. Client displays thumbnails and titles.

5.2 Video Playback Flow

1. User clicks "Play" → Client requests manifest from Video Service.
2. Video Service returns HLS manifest (.m3u8) with CDN URLs for different bitrates.
3. Client player downloads manifest and starts fetching video segments from CDN.
4. CDN serves cached segments; on cache miss, fetches from S3.
5. Player monitors bandwidth and switches bitrate dynamically (adaptive streaming).
6. Client periodically sends watch progress to Tracking Service.

5.3 Video Upload & Encoding Flow

1. Content creator uploads raw video to Upload Service.
2. Upload Service stores raw file in S3 and publishes encoding job to message queue.
3. Encoding Service consumes job and:

• Transcodes video to multiple resolutions (360p, 720p, 1080p, 4K).
• Generates thumbnails and preview clips.
• Creates HLS manifest file.
• Stores encoded files in S3.

1. CDN pre-warms cache for popular content (optional).

5.4 Recommendation Flow

1. User activity (watch events) logged to Kafka.
2. Analytics Service aggregates events and updates User Preferences DB.
3. ML Training Pipeline periodically trains models on historical data.
4. Trained models deployed to Recommendation Engine.
5. On user request, Recommendation Engine performs real-time inference and returns personalized list.

5.5 Resume Watching Flow

1. User starts watching on mobile app → Tracking Service updates watch position.
2. User switches to TV app → Client fetches watch history from Video Service.
3. Player resumes from last saved position.

6) Deep Dive A: Video Encoding & Adaptive Bitrate Streaming (~10 mins)

Problem

Users have varying bandwidth (3G to fiber). Streaming same quality to all causes buffering for slow connections and wastes bandwidth for fast connections.

Solution: Adaptive Bitrate Streaming (ABR)

6.1 Encoding Pipeline

• Input: Raw video (4K, H.264, 30 GB).
• Output: Multiple renditions (ladders):
• 360p @ 1 Mbps
• 480p @ 2 Mbps
• 720p @ 4 Mbps
• 1080p @ 8 Mbps
• 4K @ 20 Mbps
• Process:

1. Split video into segments (e.g., 10-second chunks).
2. Encode each segment at all resolutions.
3. Generate manifest file mapping segments to URLs.

6.2 HLS (HTTP Live Streaming) Protocol

• Manifest File (.m3u8):

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
https://cdn.example.com/video123/360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4000000,RESOLUTION=1280x720
https://cdn.example.com/video123/720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=8000000,RESOLUTION=1920x1080
https://cdn.example.com/video123/1080p/playlist.m3u8

• Segment Playlist (720p):

#EXTM3U
#EXTINF:10.0,
https://cdn.example.com/video123/720p/segment-001.ts
#EXTINF:10.0,
https://cdn.example.com/video123/720p/segment-002.ts
...

6.3 Client-Side ABR Logic

• Player monitors:
• Current bandwidth (measure download speed of segments).
• Buffer health (seconds of video buffered).
• Decision:
• If bandwidth high + buffer healthy → switch to higher bitrate.
• If bandwidth drops → switch to lower bitrate to avoid buffering.
• Smooth Transition: Switch at segment boundaries.

6.4 Encoding Optimization

• Parallelization: Distribute encoding across multiple workers.
• Per-Title Encoding: Optimize bitrate ladder per video (action movies need higher bitrate than cartoons).
• AV1 Codec: Roughly 30% smaller than HEVC and ~50% smaller than H.264 at similar quality (trade-off: much slower encoding, and older devices can't decode it — so keep H.264 renditions too).

6.5 Encoding Architecture

flowchart TD
    Raw["Raw Video Upload"] --> Queue["Encoding Queue<br/>(SQS)"]
    Queue --> Worker1["Encoder Worker 1"]
    Queue --> Worker2["Encoder Worker 2"]
    Queue --> WorkerN["Encoder Worker N"]
    
    Worker1 -->|"360p"| S3["S3 Storage"]
    Worker1 -->|"720p"| S3
    Worker2 -->|"1080p"| S3
    Worker2 -->|"4K"| S3
    WorkerN -->|"thumbnails"| S3
    
    S3 --> Manifest["Generate Manifest<br/>(HLS/DASH)"]
    Manifest --> MetaDB[(Metadata DB)]
    Manifest --> CDN["Pre-warm CDN Cache"]
    
    classDef worker fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    classDef storage fill:#fff9c4,stroke:#f57f17,stroke-width:2px;
    
    class Worker1,Worker2,WorkerN worker;
    class S3,MetaDB,CDN storage;

7) Deep Dive B: CDN & Content Delivery (~8 mins)

Problem

Delivering video from a central data center to global users causes high latency and bandwidth costs.

Solution: CDN (Content Delivery Network)

7.1 How CDN Works

• Edge Locations: Servers distributed globally, as close to users as possible.
• Caching: Popular content cached at edge locations near users.
• Routing: Requests are sent to a nearby, healthy edge server.
• Origin: Central storage (S3) serves as source of truth.

7.2 What Netflix Actually Does: Open Connect

Netflix's own CDN is a good example of how far this goes at ~100 Tbps:

• Caches inside ISPs: Netflix gives ISPs cache servers (Open Connect Appliances) to install in their own networks and at internet exchange points. Most video bytes never cross the wider internet.
• Proactive fill (push), not pull: The catalog is known in advance, so each night, during off-peak hours, caches are filled with what Netflix predicts that region will watch the next day. A cache miss at peak is the exception, not the design.
• Steering, not DNS: The playback service (running in AWS) picks specific caches for this client — based on which ones hold the file, their health, and network proximity — and puts those URLs in the response. The player tries them in order.
• Split planes: Control plane (sign-in, catalog, recommendations, playback decisions) runs in AWS; the data plane (video bytes) runs on Open Connect.

7.3 Cache Strategy

• Two-Tier Cache:
• Edge Cache: Near users; holds the most popular titles for the region.
• Mid-Tier / Origin Shield: Between edge and origin, reduces load on S3.
• No short TTLs: Encoded segments never change once published, so they can be cached indefinitely. What gets evicted is decided by popularity (LRU/LFU), not expiry.
• Cache Hit Ratio: Aim for 95%+ of bytes served from the edge.
• Pre-Positioning: New releases are pushed to edges before launch.

7.4 CDN Request Flow

1. Player asks the playback service for a title; it returns a manifest with URLs for specific nearby caches.
2. Player requests segments: https://cache-1.isp-x.example.net/video123/720p/segment-001.m4s.
3. Cache checks for the file:

• Cache Hit: Return segment (low latency).
• Cache Miss: Fetch from a mid-tier cache (or origin) → cache → return.

7.5 Cost Optimization

• Cache Popular Content: 20% of content drives 80% of views (Pareto principle).
• Egress Costs: CDN reduces direct S3 egress (expensive).
• Compression: Use efficient codecs (AV1) to reduce bandwidth.

7.6 CDN Architecture

flowchart LR
    User1["User (US East)"] -->|"request segment"| Edge1["Edge Location<br/>(US East)"]
    User2["User (Europe)"] -->|"request segment"| Edge2["Edge Location<br/>(Europe)"]
    User3["User (Asia)"] -->|"request segment"| Edge3["Edge Location<br/>(Asia)"]
    
    Edge1 -->|"cache miss"| Shield["Origin Shield<br/>(Mid-Tier Cache)"]
    Edge2 -->|"cache miss"| Shield
    Edge3 -->|"cache miss"| Shield
    
    Shield -->|"cache miss"| S3["Origin Storage<br/>(S3)"]
    
    classDef edge fill:#ffe0b2,stroke:#e65100,stroke-width:2px;
    classDef origin fill:#fff9c4,stroke:#f57f17,stroke-width:2px;
    
    class Edge1,Edge2,Edge3 edge;
    class Shield,S3 origin;

8) Deep Dive C: Recommendation System (~7 mins)

Problem

With 10K+ titles, users need personalized suggestions to discover content they'll enjoy.

Solution: ML-Based Recommendation Engine

8.1 Recommendation Algorithms

Collaborative Filtering

• Idea: Users with similar watch history like similar content.
• Method: Matrix factorization (user-item matrix).
• Example: If User A and User B both watched Stranger Things and The Witcher, and User A also watched Dark, recommend Dark to User B.

Content-Based Filtering

• Idea: Recommend content similar to what user watched.
• Method: Extract features (genre, actors, director) and compute similarity.
• Example: User watched action movies → recommend more action movies.

Hybrid Model

• Combine: Collaborative filtering + content-based + contextual features.
• Features:
• User: watch history, ratings, demographics.
• Content: genre, cast, popularity.
• Context: time of day, device type.
• Algorithm: Deep learning (neural networks), gradient boosting (XGBoost).

8.2 Recommendation Pipeline

1. Data Collection: Track all user interactions (watch, rate, search).
2. Feature Engineering: Extract features from raw data.
3. Model Training: Train ML models offline (daily/weekly batch jobs).
4. Model Deployment: Deploy to inference API.
5. Real-Time Serving: On user request, run model inference and return ranked list.

8.3 Architecture

flowchart TD
    User["User Interaction<br/>(watch, rate)"] --> Kafka["Kafka Event Stream"]
    Kafka --> Analytics["Analytics Service"]
    Analytics --> Warehouse["Data Warehouse<br/>(historical data)"]
    
    Warehouse --> Train["ML Training Pipeline<br/>(Spark, TensorFlow)"]
    Train --> Models["Trained Models<br/>(collaborative + content)"]
    
    Models --> Deploy["Model Serving API"]
    
    Client["User Request"] --> RecAPI["Recommendation API"]
    RecAPI --> Deploy
    RecAPI --> Features["Feature Store<br/>(user preferences)"]
    Deploy --> RecAPI
    RecAPI --> Ranked["Ranked Content List"]
    Ranked --> Client
    
    classDef ml fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
    classDef data fill:#fff9c4,stroke:#f57f17,stroke-width:2px;
    
    class Train,Models,Deploy,RecAPI ml;
    class Kafka,Analytics,Warehouse,Features data;

8.4 Personalization Strategies

• Home Page: Personalized rows ("Top Picks for You", "Trending Now", "Because You Watched X").
• A/B Testing: Experiment with different ranking algorithms.
• Cold Start Problem: For new users, use popularity-based recommendations initially.

9) Scaling & Performance (~5 mins)

Horizontal Scaling

• Microservices: Scale each service independently.
• CDN: Automatically scales with traffic.
• Encoding: Autoscale worker pool based on queue depth.

Database Scaling

• Metadata DB: Read replicas, caching (Redis).
• User Preferences DB: NoSQL (Cassandra, DynamoDB) for high write throughput.
• Sharding: Partition by user_id or video_id.

Caching Layers

• L1 (Client): Downloaded videos for offline viewing.
• L2 (CDN): Edge caches for video segments.
• L3 (Redis): Metadata cache (titles, thumbnails).

Performance Metrics

• Video Start Time (VST): < 2 seconds (time to first frame).
• Rebuffering Ratio: < 1% (percentage of playback time spent buffering).
• CDN Cache Hit Rate: > 90%.
• Encoding Speed: Real-time or faster (1 hour video → encode in < 1 hour).

10) Failure Modes & Recovery

CDN Failure

• Fallback: The manifest lists several caches per segment; the player moves to the next one. Steering stops sending clients to unhealthy caches.
• Not the origin: Origin can't absorb edge traffic (100 Tbps) — falling back to S3 at scale would take it down. Fall back to other caches or a second CDN.

Encoding Service Failure

• Retry: Failed jobs requeue with exponential backoff.
• Monitoring: Alert on stuck jobs (> 24 hours).

Recommendation Engine Failure

• Fallback: Serve popularity-based recommendations.
• Graceful Degradation: Cached recommendations.

Database Outage

• Metadata DB: Serve stale cache; read-only mode.
• User DB: Queue writes to Kafka, replay after recovery.

Regional Outage

• Multi-Region: Deploy in multiple AWS regions.
• Failover: DNS routes to healthy region.

11) Trade-offs & Alternatives

HLS vs DASH

• HLS (Apple): Better iOS/Safari support.
• DASH: Open standard, more flexible.
• Choice: Support both or use HLS (wider adoption).

Live Encoding vs Pre-Encoding

• Pre-Encoding: Encode on upload (better quality, consistent).
• Live Encoding: Encode on-demand (saves storage, slower start).
• Choice: Pre-encode everything. A VOD catalog is known ahead of time and storage is cheap next to bandwidth. On-demand transcoding fits user-generated long-tail content (YouTube-style), not a curated catalog.

Push vs Pull CDN

• Push: Upload to CDN directly (proactive).
• Pull: CDN fetches from origin on demand (reactive).
• Choice: Push at Netflix's scale — the catalog is finite and viewing is predictable, so caches are filled off-peak. Pull (a commercial CDN) is simpler and the right call for a smaller service.

Cloud vs On-Premise Encoding

• Cloud (AWS MediaConvert): Elastic scaling, managed.
• On-Premise: Lower cost at scale, full control.
• Netflix: Encodes in the cloud (AWS) with its own pipeline, splitting titles into chunks encoded in parallel. What Netflix runs itself is delivery (Open Connect), not encoding.

12) Security & Compliance

DRM (Digital Rights Management)

• Protect premium content from piracy.
• Use Widevine (Google), FairPlay (Apple), PlayReady (Microsoft).

Authentication & Authorization

• JWT tokens for API access.
• Token refresh for long sessions.

Content Encryption

• Encrypt video segments (AES-128).
• Secure manifest URLs with signed tokens.

GDPR & Privacy

• User consent for tracking.
• Right to delete watch history.

13) Interview Time Allocation (45 min)

• 5 min: Requirements & scope (functional, non-functional, scale).
• 10 min: HLD & architecture diagram (components, data flow).
• 5 min: Data model & key flows (playback, upload, encoding).
• 10 min: Deep dive on video encoding & adaptive bitrate streaming.
• 8 min: Deep dive on CDN & content delivery.
• 5 min: Recommendation system overview.
• 2 min: Scaling, failure handling, wrap-up.

14) Summary

• Core Challenges: Global video delivery (CDN), adaptive streaming (ABR), petabyte-scale storage, personalized recommendations.
• Key Components:
• Encoding Pipeline: Transcode to multiple formats, parallelized workers.
• CDN: Edge caching for low-latency delivery.
• Recommendation Engine: ML models (collaborative + content-based filtering).
• Tracking: Real-time event streaming for watch progress and analytics.
• Scaling Strategy: Microservices, CDN auto-scaling, NoSQL for high writes, multi-region deployment.
• Performance: Video start time < 2s, rebuffering < 1%, cache hit rate > 90%.

This architecture supports 200M+ users streaming billions of hours monthly (~20M concurrent streams at peak) with seamless playback and personalized experiences.