The Question
Design

Scalable Video Sharing Platform Design

Design a high-scale video sharing platform similar to YouTube. The system must support reliable video uploads from a global user base, asynchronous processing of videos into multiple resolutions and formats (transcoding), and low-latency video streaming. Discuss how you would handle massive storage requirements (PB scale), optimize content delivery via CDNs, manage video metadata, and ensure the system remains highly available even during viral traffic spikes. Address trade-offs between upload latency and processing completeness.
S3
Kafka
Cassandra
Redis
CDN
FFmpeg
HLS
DASH
NoSQL
JWT
Prometheus
Questions & Insights

Clarifying Questions

Scale & Traffic: What is the expected scale for Daily Active Users (DAU) and the ratio of uploaders to viewers?
Assumption: 100M DAU, 1:100 upload-to-view ratio. Approximately 1M video uploads per day.
Video Specifications: What are the constraints on video length and resolution?
Assumption: Support up to 4K resolution and up to 15-minute videos for the MVP.
Latency Requirements: Is real-time streaming (Live) in scope, or just Video-on-Demand (VoD)?
Assumption: Only VoD is in scope for the MVP.
Consistency vs. Availability: Is it acceptable for view counts or comments to be eventually consistent?
Assumption: High availability is preferred over strong consistency for metadata like view counts and comments.

Thinking Process

Core Bottleneck: The primary challenge is the massive bandwidth and storage required for video files and the CPU-intensive nature of video transcoding.
Progressive Walkthrough:
How do we handle large file uploads reliably? (Chunked uploads + Object Storage).
How do we make videos playable across all devices? (Asynchronous transcoding pipeline).
How do we serve video content globally with low latency? (CDN + Adaptive Bitrate Streaming).
How do we manage massive metadata and view counts? (Scalable NoSQL + Write-back caching).

Bonus Points

Adaptive Bitrate Streaming (ABR): Implementing DASH (Dynamic Adaptive Streaming over HTTP) or HLS to adjust video quality dynamically based on user network conditions.
Video Deduplication: Using SHA-256 or perceptual hashing at the upload gate to save storage costs by identifying identical content.
Edge Side Rendering/Compute: Using Lambda@Edge for localized manifests or security checks to reduce origin load.
Cost-Optimized Storage: Implementing lifecycle policies to move older, less-popular videos from S3 Standard to Cold Storage (e.g., Glacier).
Design Breakdown

Functional Requirements

Core Use Cases:
Users can upload videos.
Users can view videos (streaming).
Users can search for videos by title.
Users can see video metadata (view counts, descriptions).
Scope Control:
In-scope: Video upload, transcoding, global delivery, basic metadata.
Out-of-scope: Live streaming, social features (likes/comments), recommendations engine, monetization/ads.

Non-Functional Requirements

Scale: Must handle 1M uploads and 100M views daily.
Latency: Video playback should start in < 200ms (Time to First Frame).
Availability & Reliability: 99.99% availability for playback. No data loss for uploaded videos.
Consistency: Metadata (titles) should be highly consistent; view counts can be eventually consistent.
Security: Content protection via signed URLs; TLS for all transfers.

Estimation

Traffic Estimation:
Uploads: 1,000,000 / 86,400s \approx 12 writes/sec.
Views: 100,000,000 / 86,400s \approx 1,150 reads/sec.
Peak QPS: \approx 5,000.
Storage Estimation:
1M videos/day * 100MB avg size = 100TB/day.
1 year storage = 36.5 PB (Raw). Transcoding into 5 formats triples this to \approx 110 PB/year.
Bandwidth Estimation:
Ingress: 12 videos/s * 100MB = 1.2 GB/s (9.6 Gbps).
Egress: 1,150 views/s * 50MB (avg watched) = 57.5 GB/s (460 Gbps).

Blueprint

Concise Summary: A cloud-native architecture utilizing chunked uploads to Object Storage, an asynchronous transcoding pipeline triggered by message queues, and global delivery via a CDN.
Major Components:
API Gateway: Handles authentication and routes requests to metadata or upload services.
Upload Service: Manages multi-part uploads and initial file validation.
Transcoding Workers: Converts raw videos into multiple resolutions (1080p, 720p, 480p) and segments them for streaming.
Object Storage: Acts as the source of truth for raw and processed video files.
CDN: Caches video segments at edge locations close to users.
Metadata DB: Stores video info and user data.
Simplicity Audit: This design avoids complex micro-services for the MVP, focusing on the critical path of "Upload -> Process -> Serve".
Architecture Decision Rationale:
Why this architecture?: Decoupling transcoding via a queue prevents upload timeouts and allows independent scaling of compute-heavy tasks.
Functional Satisfaction: Covers the full lifecycle from upload to playback.
Non-functional Satisfaction: CDN ensures low latency; NoSQL provides horizontal scale for metadata.

High Level Architecture

Sub-system Deep Dive

Edge (Optional)

Content Delivery & Traffic Routing:
CDN: Use a global CDN (e.g., CloudFront) to cache video segments (.ts or .m4s files) and manifests (.m3u8 or .mpd).
DNS: Latency-based routing to direct users to the nearest API endpoint.
Security:
API Gateway: Performs JWT validation and rate limiting (e.g., 10 uploads/hour per user) to prevent DDoS.
SSL: TLS 1.3 termination at the Load Balancer.

Service

Topology & Scaling: Stateless microservices deployed in EKS (Kubernetes) across multiple Availability Zones. Scaling is based on CPU/Request count.
API Schema Design:
POST /v1/uploads: Initiates a session. Returns upload_id and signed S3 URL.
GET /v1/videos/{id}: Returns video metadata and the CDN URL for the manifest.
GET /v1/search?q=...: Query-based search.
Resilience:
Retries: Client-side exponential backoff for chunked uploads.
Circuit Breaker: Implemented in the API Gateway to protect the Metadata DB from being overwhelmed during traffic spikes.

Storage

Access Pattern:
Metadata: Heavy read (views) / Moderate write (uploads/updates).
Video Files: Write once, Read many.
Database Table Design (NoSQL - Cassandra):
Videos Table: video_id (PK), uploader_id, title, description, s3_path, status (processing/ready), created_at.
Search Index: Handled via ElasticSearch/OpenSearch (fed by CDC from Cassandra).
Technical Selection:
Object Storage (S3): For high durability and cost-effective scaling of large binaries.
NoSQL (Cassandra): For high-availability metadata storage that scales linearly.

Cache

Purpose: Reduce latency for video metadata lookups and offload the primary database.
Key-Value Schema:
Key: vid:{video_id}, Value: JSON-serialized metadata.
TTL: 1 hour (longer for popular videos).
Technical Selection: Redis. Selected for its support of complex data structures (like Sorted Sets for trending videos).
Failure Handling: If Redis fails, the system falls back to the Metadata DB (Performance degradation, but functional).

Messaging

Purpose: Decouples the time-consuming transcoding process from the user-facing upload service.
Event Schema: { "video_id": "123", "raw_path": "s3://raw/123.mp4", "format": ["1080p", "720p"] }.
Failure Handling: Dead Letter Queue (DLQ) for videos that fail transcoding more than 3 times (e.g., corrupted files).
Technical Selection: Kafka. High throughput and message persistence allow replaying failed jobs.

Data Processing

Processing Model: Distributed workers pulling tasks from Kafka.
Processing DAG:
Pull raw video from S3.
Transcode into multiple bitrates using FFmpeg.
Generate thumbnails.
Segment video for DASH/HLS.
Update Video Status in Metadata DB.
Technical Selection: FFmpeg-based Custom Workers running on GPU-optimized instances.
Wrap Up

Advanced Topics

Trade-offs: We chose Eventual Consistency for the view count. A "Counter Service" using Redis INCR can buffer view counts before flushing to the DB to prevent hot-partition issues in Cassandra.
Reliability: Multi-part upload allows users to resume uploads if the connection drops.
Bottleneck Analysis: The "Hot Video" problem (viral content) is mitigated by the CDN and Redis caching.
Optimization: Pre-signed URLs allow clients to upload directly to S3, bypassing the Upload Service for the actual data transfer, significantly reducing the load on internal servers.