Design a Video Streaming Platform — Cheat Sheet

A video streaming platform must handle two fundamentally different traffic patterns: infrequent, large creator uploads and continuous, high-concurrency viewer streams. Uploaded raw video must be durably stored, asynchronously transcoded into multiple resolution renditions, segmented for HTTP-based adaptive streaming, and distributed to a globally replicated CDN. Viewers receive only small segment fetches — the quality level adapts per segment based on real-time bandwidth — so no single server ever carries a full video stream.

• ✓Creators upload video files (up to 256 GB) via a resumable, chunked upload mechanism
• ✓The platform transcodes each upload into multiple resolutions: 360p, 720p, 1080p, and 4K
• ✓Viewers can search for and browse videos by title, tag, and category
• ✓Video playback adapts quality in real-time based on viewer bandwidth (adaptive bitrate)
• ✓Creators and viewers receive notifications when processing completes or a subscribed channel uploads
• ✓View counts, likes, and comments are recorded per video

• ✓Upload volume: 500 hrs/min × 60 min = 30,000 hrs/hr of raw video
• ✓Raw storage per hour of video: ~7 GB (1080p H.264 source)
• ✓Transcoded storage per video (all resolutions): ~3.5 GB/hr (360p 0.3 + 720p 0.9 + 1080p 1.5 + 4K 3.5 ≈ 6.2 GB avg)
• ✓New processed storage per day: 720,000 hrs/day × 3.5 GB ≈ 2.5 PB/day
• ✓Peak concurrent streams: 10M streams × 4 Mbps avg ≈ 40 Tbps egress
• ✓CDN PoPs required: ~200 PoPs each serving ~200 Gbps = 40 Tbps

• ✓Upload Service — Accepts chunked, resumable multipart uploads from creators. Issues pre-signed S3 URLs for direct chunk upload, tracks upload state in Redis, and publishes a VideoUploaded event to the transcoding queue when all chunks have been received and assembled.
• ✓Raw Video Store (S3) — Object storage bucket for raw creator uploads. Versioning disabled (immutable objects). Lifecycle policy moves objects to Glacier after 90 days post-processing. Serves as the durable source of truth for re-transcoding runs.
• ✓Transcoding Queue (Kafka / SQS) — Decouples the upload path from the CPU-intensive transcode path. Each VideoUploaded event is a message carrying the raw S3 key and target rendition set. Consumers are stateless worker pods that auto-scale based on queue depth.
• ✓Transcoder Workers — Stateless pods (GPU-enabled for H.265/AV1) running FFmpeg. Each worker processes one transcode job: downloads the raw source from S3, encodes the target resolution, segments the output into HLS .ts chunks, and uploads segments + playlist to the processed S3 bucket.
• ✓Processed Video Store (S3) — Object storage bucket for HLS segments (.ts files) and playlists (.m3u8 files) for all renditions. Organised as {videoId}/{rendition}/segNNN.ts. This bucket is the CDN origin — all CDN edge nodes pull segments from here on cache miss.
• ✓CDN (CloudFront / Fastly) — Globally distributed edge network with 200+ PoPs. Serves segment and manifest requests directly from edge cache. Cache TTL for segments is 7 days (immutable); manifests use shorter TTLs (60s) to allow adaptation. Geo-routing directs each viewer to the nearest healthy PoP.

• ✓HLS vs DASH → Both (HLS for Apple, DASH elsewhere): Apple's Safari and iOS do not support DASH natively — HLS is mandatory on those platforms. DASH is an open ISO standard with better tooling on Android and Smart TVs. Using CMAF (fragmented MP4) for the underlying segments allows a single set of segment files to be referenced by both manifests, keeping storage cost the same as using only one protocol.
• ✓Push CDN vs pull CDN → Pull CDN with selective push for trending content: A push CDN pre-populates all content at all edges — prohibitively expensive for a long-tail platform with billions of videos, most of which are watched infrequently. A pull CDN only stores content at an edge node once a viewer in that region requests it. Selective push (first 30 seconds to top-10 PoPs for trending videos) eliminates cold start for the small subset of content that will receive simultaneous viral traffic.
• ✓Centralised vs distributed transcoding → Distributed (message queue + stateless worker pool): A centralised transcoding server creates a single point of failure and cannot scale horizontally without coordination. A message queue (Kafka/SQS) decouples upload from transcoding, provides natural backpressure, and allows the worker pool to scale horizontally based on queue depth. Workers are stateless — any worker can process any job — enabling spot-instance or preemptible-VM usage for 60–80% cost reduction versus reserved instances.
• ✓Segment length: 2s vs 4s vs 10s → 4 seconds: 2-second segments react faster to bandwidth changes but generate 2× the number of HTTP requests and S3 objects, increasing CDN overhead and manifest size. 10-second segments reduce request count but react slowly to bandwidth drops, causing long stall events. 4 seconds is the industry consensus (used by YouTube, Netflix VOD, and HLS spec examples) — fast enough for smooth ABR quality switching, minimal enough in request overhead for practical CDN caching.

• ✓Separate the upload path from the playback path early in your design. Creators upload raw video to object storage — viewers never touch the raw file. The CDN serves only processed segments. This separation is the first thing interviewers evaluate.
• ✓Explain why pre-signed URLs are used for uploads. The Upload Service issues pre-signed S3 URLs so video bytes flow directly from the creator's client to S3, bypassing your application servers. This prevents the service from being a bandwidth bottleneck and is a standard FAANG upload pattern.
• ✓Know the HLS manifest hierarchy: master playlist → per-rendition playlist → segment files. Interviewers will ask you to sketch this. Also know that manifests have short TTLs (60s) while segments are immutable with long TTLs (7 days).
• ✓For ABR, name both inputs: estimated bandwidth (EWMA of recent segment download speeds) and buffer occupancy. Buffer-based ABR (BOLA) is more stable than pure throughput-based. Mention the panic threshold (drop to lowest quality below 5s buffer) — it shows you've thought about the worst case.
• ✓On CDN, avoid the shallow answer of "use CloudFront." Explain the pull model, request coalescing for viral cold-start, TTL differences between segments and manifests, and how invalidation works on delete. These details differentiate senior from mid-level candidates.
• ✓Common mistake: designing the transcoding as a synchronous in-request operation. Always make transcoding async via a queue. The upload returns a `videoId` with status `PROCESSING`; the client polls or receives a push notification when the video is `READY`.