Design a Video Streaming Platform (YouTube / Netflix)

Clarifying questions I'd ask first

• VOD only, live, or both?
• Resolutions and codecs — 4K HDR, AV1 alongside H.264?
• DRM required?
• UGC (YouTube) or curated catalog (Netflix)?
• Captions, recommendations, offline downloads in scope?
• Latency requirement for live?

Assumptions for this design

VOD primary with optional live. UGC like YouTube. Resolutions 240p–4K, codecs H.264 + H.265 + AV1. HLS primary with DASH alongside. 500M DAU, 100M concurrent peak. 500 hours uploaded per minute. Sub-2-second startup. Multi-CDN. Tiered storage.

Quick capacity check

• Egress: 100M concurrent × 2 Mbps avg = 200 Tbps at peak — essentially all from CDN edge
• Storage: 720 TB/day net new; ~1.3 EB over 5 years
• Transcoding: ~50,000 cores at peak with chunked parallelism
• Bandwidth dominates the cost — CDN topology and caching are the first decisions

Why HLS/DASH and adaptive bitrate

• Source video chopped into 4-6s segments; multiple bitrate ladders
• Manifest file lists all renditions and their segments
• Player measures bandwidth, switches renditions per segment
• Rejected single-MP4 streaming — no bitrate adaptation, unwatchable on slow connections, no DRM-friendly format

Transcoding pipeline — chunked parallel

• Single-stream FFmpeg on a 4-hour movie takes 4 hours per rendition; with 10 renditions that's 40 hours — unacceptable
• Split source by keyframes into 30-second chunks; distribute to worker pool; each worker transcodes its chunk to all renditions; stitch outputs back into HLS/DASH segments
• 480 workers process a 4-hour movie in ~30 seconds wall clock per rendition
• Per-title encoding (Netflix's approach): analyze content complexity, pick bitrate per rendition that hits target VMAF — saves bandwidth on simple content
• VMAF scores below threshold flag for re-encode

High-level shape

• Upload: pre-signed S3 URL → source upload → enqueue chunk tasks to Kafka → worker pool transcodes → outputs to S3 → packager generates manifests → metadata service marks available
• Playback: player fetches master manifest from CDN edge → picks rendition → fetches segment manifest + segments via CDN → origin only on edge miss
• Analytics: player emits view events to ingestion service → Cassandra → aggregator rolls up periodic stats to PostgreSQL

CDN strategy — multi-tier and multi-CDN

• Multi-tier: 1000+ edge POPs → ~50 regional mid-tiers → multi-region origin
• Edge hit rate ~80% for hot videos; mid-tier reduces origin egress further to ~5-10% of total
• Multi-CDN (2-3 providers) for resilience and cost arbitrage
• Segments are immutable and content-addressable; cache key is videoId/rendition/segNum; cache forever
• Manifests have shorter TTL (live: ~2x segment duration; VOD: hours)

Storage tiering

• Hot S3 Standard for top 10% by recency/popularity
• Warm S3 Standard-IA for the long tail (~50% cheaper)
• Cold Glacier for unwatched 6+ months
• Source files kept in IA after transcoding; deleted after 90 days for free-tier UGC

Data model

• videos (sharded PostgreSQL) — metadata, status, source key
• video_renditions — per-rendition info: codec, bitrate, S3 prefix
• view_events (Cassandra) — wide-column, partitioned by (video_id, time bucket)
• video_stats — aggregated counters for fast read

LLD — clean abstractions

• StorageClient interface (S3 impl; could swap to GCS)
• FfmpegRunner for transcoding; isolated for A/B-testing encoder versions or hardware
• QualityValidator for VMAF/PSNR/SSIM
• TranscodingCoordinator tracks chunk completion per video; finalizes when all chunks land
• HlsPackager builds manifests
• Per-title bitrate selection added in scheduler before publishing tasks

Live streaming — different beast

• Continuous ingest via RTMP/SRT/WebRTC; real-time transcoding; rolling manifest with segment expiry
• Glass-to-glass latency: ~30s for traditional, ~3s for low-latency HLS, ~500ms for WebRTC
• LL-HLS uses partial segments (~200ms each) pushed via HTTP/2 Server Push
• WebRTC for sub-second interactive (chat-relevant); needs SFU for one-to-many

Failure handling

• Transcoder crash: Kafka redelivers; FFmpeg output is idempotent on S3 key
• Origin outage: CDN serves cached content; multi-region origin failover
• CDN POP failure: DNS routes to next POP; multi-CDN picks alternate provider
• Player buffer underrun: ABR drops rendition; on empty, brief spinner
• Bad transcode: VMAF catches; flag for re-encode; remove from manifest until fixed
• Viral spike: CDN absorbs (immutable segments cache perfectly)

Production extras

• DRM (Widevine/PlayReady/FairPlay) packaged at transcode time for premium content
• Token-based CDN edge authorization for entitlements (geo, subscription, age-gate)
• Multi-DRM, geo-blocking, hot-link prevention
• ML-based content moderation; manual review for flagged
• Content fingerprinting for copyright detection
• Per-playback distributed tracing for debugging quality issues

At 10× scale

• ISP-embedded servers (Netflix Open Connect)
• AV1 default for bandwidth savings
• ML-based per-viewer rendition prediction
• Edge transcoding for live

Recommendation

Async chunked transcoding pipeline producing HLS/DASH segments with per-title bitrate ladders, multi-tier multi-CDN delivery, adaptive bitrate playback, tiered S3 storage matching the long-tail viewing distribution, and a separate live pipeline using RTMP/SRT ingest with LL-HLS or WebRTC depending on latency target — the same architecture YouTube, Netflix, and Twitch run for video at scale.