The Question
Design

Global Video Streaming & Sharing System

Design a high-scale video sharing platform similar to YouTube. The system must support reliable video uploads from a global user base, asynchronous processing/transcoding of videos into multiple formats, and low-latency global playback for billions of users. Address how you would handle massive storage requirements, bandwidth costs, and the consistency of video metadata and view counts under high concurrency.
S3
CDN
Kafka
Redis
PostgreSQL
FFmpeg
HLS
DASH
Kubernetes
gRPC
Questions & Insights

Clarifying Questions

What is the expected scale of the system? (Assumption: 2 Billion Monthly Active Users, 500 million Daily Active Users. 100:1 Read/Write ratio).
What are the primary video constraints (length/resolution)? (Assumption: Support up to 4K resolution, 1GB file size per upload for MVP).
Is real-time "Live Streaming" in scope? (Assumption: No, focus on Video-on-Demand (VoD) for the MVP).
How should we handle global latency? (Assumption: Viewers are global; creators are global. Use CDN for delivery).
What is the consistency requirement for view counts? (Assumption: Eventual consistency is acceptable; low latency playback is the priority).

Thinking Process

Core Bottleneck: High-bandwidth video ingestion and global low-latency delivery.
Key Strategy: Separate the Upload Path (heavy write, async processing) from the Playback Path (heavy read, CDN-cached).
Progressive Logic:
How do we handle large file uploads reliably? (Multipart uploads to Object Storage).
How do we make videos playable on all devices? (Asynchronous transcoding pipeline via Message Queues).
How do we scale reads globally? (Aggressive CDN caching and metadata replication).
How do we handle metadata and search? (Relational DB for consistency + Search Engine for discovery).

Bonus Points

Adaptive Bitrate Streaming (ABS): Implementing DASH (Dynamic Adaptive Streaming over HTTP) or HLS to ensure smooth playback under varying network conditions.
Cost Optimization: Using tiered storage (Hot/Cold) for videos. Older, unpopular videos move to cheaper storage classes (e.g., S3 Glacier).
Geographic Request Steering: Using Anycast DNS and Geo-IP to route users to the closest POP (Point of Presence).
Edge Side Rendering/Compute: Offloading thumbnail generation or basic metadata logic to CDN edges to reduce origin load.
Design Breakdown

Functional Requirements

Core Use Cases:
Users can upload videos.
Users can view/stream videos (Playback).
Users can search for videos by title.
System tracks view counts.
Scope Control:
In-Scope: VoD upload, transcoding, global delivery, basic search, metadata management.
Out-of-Scope: Live streaming, social features (comments/likes), recommendation engine (AI/ML), monetization/ads.

Non-Functional Requirements

Scale: Support 5M video uploads/day and 500M views/day.
Latency: Playback start latency < 200ms (via CDN); Upload processing is asynchronous.
Availability & Reliability: 99.99% availability for playback. No data loss for uploaded videos.
Consistency: Strong consistency for video metadata; eventual consistency for view counts.
Security: Support for private/public video permissions and HTTPS delivery.

Estimation

Traffic Estimation:
Write QPS: 5M uploads / 86400s ≈ 60 uploads/sec.
Read QPS: 500M views / 86400s ≈ 6,000 views/sec (Avg), Peak ~15,000 views/sec.
Storage Estimation:
5M videos/day * 100MB (avg compressed size) = 500 TB/day.
1 Year storage = ~180 PB. (Requires tiered storage).
Bandwidth Estimation:
Ingress: 60 uploads/sec * 100MB = 6 GB/s.
Egress: 6,000 views/sec * 100MB (assuming full watch) = 600 GB/s (Offloaded primarily to CDN).

Blueprint

Concise Summary: An event-driven architecture that decouples video ingestion from consumption. Videos are uploaded to a staging area, processed asynchronously into multiple formats, and served via a global CDN.
Major Components:
Upload Service: Orchestrates multipart uploads and metadata entry.
Transcoding Workers: Distributed workers that convert raw video into multiple resolutions (360p, 720p, 1080p) and segments (HLS/DASH).
Object Storage: The source of truth for all video blobs (Original + Transcoded).
CDN: Caches video segments at the edge for low-latency global delivery.
Metadata DB: Stores video info, user info, and pointers to storage.
Simplicity Audit: This design avoids complex microservices by focusing on the critical "Upload -> Transcode -> Stream" pipeline. We use Managed Object Storage and CDNs to offload the heaviest infrastructure burdens.
Architecture Decision Rationale:
Why this architecture?: Video files are too large for synchronous processing. An async, queue-based pipeline ensures the system remains responsive during peak upload periods.
Functional Satisfaction: Covers upload, storage, and playback.
Non-functional Satisfaction: CDN ensures scalability and availability; Object Storage ensures durability.

High Level Architecture

Sub-system Deep Dive

Edge (Optional)

Content Delivery & Traffic Routing:
CDN Strategy: Use a multi-CDN strategy (Cloudflare/Akamai) to deliver video segments (.ts or .m4s). Use "Push" for extremely popular videos and "Pull" (Origin Fetch) for long-tail content.
DNS: Latency-based routing to direct users to the nearest API Gateway or CDN PoP.
Security:
API Gateway: Handles JWT-based authentication and TLS termination.
Rate Limiting: Applied at the user level to prevent DoS on the upload endpoint.

Service

Topology & Scaling:
Stateless Services: All services (Upload, Playback, Metadata) are stateless and deployed in Kubernetes across multiple Availability Zones.
Scaling: Upload service scales on Request Count; Transcoding workers scale based on Queue Depth (Kafka/SQS lag).
API Schema Design:
POST /v1/video/upload: Initiates multipart upload. Returns upload_id and S3 pre-signed URLs.
GET /v1/video/:id: Returns metadata + manifest URL (HLS/DASH) for playback.
GET /v1/search?q=query: Returns a list of video objects.
Resilience:
Retries: Exponential backoff for transcoding jobs.
Graceful Degradation: If the search service is down, show "Trending" or "Featured" cached videos.

Storage

Access Pattern:
Metadata: High read (viewing), low write (uploading).
Video Blobs: Write once, Read many.
Database Table Design (PostgreSQL):
videos: id (PK), user_id, title, description, s3_path, status (processing/ready), created_at.
video_variants: id, video_id, resolution (720p/1080p), format (HLS/DASH), url.
Technical Selection:
PostgreSQL: For video metadata due to ACID requirements for user data.
Object Storage (S3): For binary data. It provides 99.999999999% durability.
Distribution Logic:
Metadata DB sharded by video_id to distribute load.

Cache

Purpose: Reduce Metadata DB load and store hot view counts.
Key-Value Schema:
video_meta:{id} -> JSON blob of video details. TTL: 1 hour.
view_count:{id} -> Atomic Counter. TTL: None. Periodically flushed to DB.
Technical Selection: Redis. Support for atomic increments (INCR) makes it ideal for view counts.

Messaging

Purpose: Decouples upload completion from time-consuming transcoding.
Event Schema: { video_id: "123", s3_raw_path: "s3://raw/123.mp4", timestamp: 1672531200 }.
Failure Handling: Dead-Letter Queue (DLQ) for videos that fail transcoding after 3 retries (e.g., corrupt files).
Technical Selection: Kafka. High throughput and message persistence allow re-processing if workers fail.

Data Processing

Processing Model: Distributed workers pulling from Kafka.
Processing DAG:
Pull: Fetch raw video from S3.
Transcode: Use FFmpeg to generate different resolutions.
Segment: Split videos into 5-10 second chunks.
Thumbnail: Generate JPEG previews.
Upload: Push processed assets back to S3.
Update DB: Mark video status as "Ready".
Technical Selection: Custom Worker Pool (Golang/C++ with FFmpeg) for performance.

Infrastructure (Optional)

Observability: Prometheus for metrics (Red/USE), ELK stack for logs, and Jaeger for tracing the lifecycle of an upload.
Wrap Up

Advanced Topics

Trade-offs: We chose Eventual Consistency for view counts. A user might see 1.1M views while another sees 1.15M. This sacrifice allows the system to handle massive read volume without a centralized lock.
Reliability: If S3 is unavailable in one region, we use cross-region replication (CRR) to failover to a secondary bucket.
Bottleneck Analysis:
Hot Videos: A viral video can overwhelm a single cache node. Solution: Use Cache Replication or CDN Tiered Caching (Shield).
Large Uploads: Users with slow connections. Solution: Multipart uploads with resumable state (AWS S3 Transfer Acceleration).
Security: Pre-signed URLs ensure that only authenticated users can upload directly to our storage buckets, minimizing the risk of unauthorized resource consumption.