System Design: Video Streaming Platform (like YouTube)

One service, one endpoint. POST /api/videos streams the whole file through your web server onto attached storage; GET streams it back out. Metadata is a row in SQL. For a handful of videos this genuinely works.

Then say the sizes out loud: a single upload is ~200 MB, and a flaky mobile connection at minute nine of a ten-minute upload restarts from zero. Your web server is now a file-transfer proxy burning connections on multi-minute requests, and every viewer pulls the one original file at whatever bitrate their network can't sustain.

The fix is to stop proxying bytes. POST /api/videos creates the metadata record and returns a signed URL; the client uploads directly to object storage (S3/GCS) in chunks, each retryable and idempotent under an uploadId. A dropped connection resumes at the last acknowledged chunk instead of restarting.

When the final chunk lands, storage emits a completion event onto an event bus. Your API tier never touched the video — it only brokered permission. This is the upload contract interviewers want stated explicitly: signed URLs, chunking, idempotency, resume.

One file can't serve a phone on 3G and a TV on fiber. The completion event feeds Kafka; a fleet of transcoding workers fans each video out into ~6 renditions (multiple resolutions and bitrates), segments them for HLS/DASH, and writes results back to object storage before flipping the metadata row to available.

Renditions add roughly ~0.6x the original size — on the order of another ~120 TB/day — and peak load wants ~tens of thousands of concurrent transcode jobs, so the fleet autoscales on queue depth. Jobs must be idempotent: a worker that dies mid-encode gets its job redelivered, and re-running it must be safe.

Playback is GET manifest.m3u8 → signed CDN URLs → the player adaptively picks renditions segment by segment. At ~5M concurrent viewers around ~3 Mbps, egress is on the order of ~15 Tbps — your origin cannot serve that, so you need a >95% CDN offload rate, with an origin shield collapsing edge misses so storage sees one fetch per segment, not thousands.

Private and unlisted videos ride the same edge: tokens embedded in the signed segment URLs are validated at the POP, so authorization never adds an origin round trip. Playback start under ~2 s comes from the manifest listing a low-bitrate first segment the edge almost certainly has cached.

Likes and comments are high-write, low-consistency data — they go to a NoSQL store plus a search index, not the relational metadata DB. Watch events stream into the analytics lake, powering creator dashboards that are eventually consistent by design; nobody needs view counts accurate to the second.

Moderation is the lane candidates forget: an ML service scores every upload for risk during processing, flagged content routes to a human review tool that fetches assets via signed URLs, and copyright fingerprinting (Content ID-style) runs as one more consumer of the same processing events. Raising takedowns unprompted is a strong senior signal.