Design Video Streaming / VOD (YouTube/Netflix)

Two problems bolted together

Video is two very different problems bolted together: an asynchronous ingest/transcoding pipeline (write path, minutes of latency, compute-heavy) and a delivery path (read path, milliseconds, bandwidth-heavy, CDN-dominated). Conflating them is the classic mistake. A single 4K source uploaded once may be watched a billion times, so the economics are entirely about the read path and egress cost.

Ingest and transcoding

A raw upload lands in object storage (S3). You never serve that file. Instead a job is enqueued (SQS/Kafka) and a fleet of transcoding workers produces an ABR ladder: the same content re-encoded at multiple resolutions and bitrates (for example 240p at 400kbps, 480p, 720p, 1080p, 4K), each in modern codecs (H.264 for compatibility, plus H.265/VP9/AV1 for efficiency). Transcoding is embarrassingly parallel: split the video into segments, transcode segments across many workers, then assemble. Each rendition is cut into short segments (2 to 10 seconds) and described by a manifest (an HLS .m3u8 or DASH .mpd) that lists the available bitrates and segment URLs.

upload --> S3 (raw) --> transcode queue --> worker pool (segment-parallel)
   --> renditions [240p 480p 720p 1080p 4K] x segments --> manifest (HLS/DASH) --> object store --> CDN

Adaptive bitrate

The player, not the server, drives quality. It downloads the manifest, measures throughput and buffer level, and requests the next 4-second segment at whatever bitrate it can sustain. Bandwidth drops on a train, the player steps down to 480p mid-stream and steps back up later, all by choosing different segment URLs from the same manifest. This is why segmentation and per-bitrate manifests exist: they make quality a client-side, per-segment choice with no server session state.

CDN, origin offload, and tiering

You must not serve segments from origin; a viral video would saturate origin egress and bankrupt you. Segments are cached at CDN edge PoPs close to viewers. Netflix built Open Connect, placing its own caches inside ISPs; YouTube uses Google's edge. The cache key is the segment URL, and because segments are immutable you cache them with long TTLs. For a live spike (a premiere), you pre-warm edges and rely on the CDN's request coalescing so a million viewers of the same segment produce one origin fetch.

The vast majority of the catalog is watched rarely. Keep hot content on fast storage and at many edges; tier cold content to cheaper storage (S3 Infrequent Access / Glacier) and fewer edges, re-warming on demand. Metadata and recommendations are a completely separate serving path from delivery.

Interview nuance: interviewers love "what happens the instant a video goes viral." The right answer names CDN request coalescing and edge caching absorbing the read fan-out, plus the fact that transcoding already happened once at upload so the spike is pure cached reads, not compute. If you find yourself scaling transcoding for a viral watch spike, you have conflated the write and read paths.

Recap: transcode once, asynchronously, into an ABR ladder of segmented renditions with manifests; let the client adapt bitrate per segment; and serve segments from a CDN (Open Connect-style edge caches) with long TTLs so origin egress stays flat even under viral read spikes.