Design YouTube or Netflix

YouTube and Netflix both deliver video to hundreds of millions of screens, at whatever quality each viewer's connection can handle. YouTube also takes in hundreds of hours of uploads every minute. The design splits into two very different halves: an upload and transcoding pipeline, and a global delivery network.

Requirements#

Functional

• Creators upload videos; viewers watch them on any device.
• Playback adapts to bandwidth, with no buffering when the connection drops.
• Search, recommendations, view counts and comments.

Non-functional

• Playback starts in under 2 seconds, with minimal rebuffering.
• Uploaded videos are never lost.
• Bandwidth is the dominant cost, so delivery must be as cheap as possible.

Estimates#

Upload and transcoding#

1. Resumable uploads: the client uploads in chunks so a dropped connection resumes instead of restarting.
2. Transcoding: the video is split into short segments and encoded in parallel into many resolutions (240p to 4K) and codecs (H.264, VP9, AV1). Parallel segments turn a one-hour encode into minutes.
3. Packaging: each rendition is cut into 2 to 6 second chunks with a manifest file (HLS or DASH).
4. Publishing: metadata is written and the video becomes watchable, starting with lower resolutions while higher ones finish.

Adaptive bitrate streaming#

The player downloads the manifest first, which lists every quality level and its chunk URLs:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/index.m3u8

It then fetches chunks one by one, measuring throughput and buffer size. If bandwidth drops, the next chunk comes from a lower rendition. This is why a video gets blurry for a moment instead of stopping.

Delivery through CDNs#

Chunks are plain static files, ideal for caching. They are served from CDN edge servers close to viewers. Netflix goes further with Open Connect: its own cache appliances inside ISPs, pre-filled overnight with the titles each region is likely to watch.

• Popular videos stay hot at the edge.
• The long tail of rarely watched videos is served from regional caches or origin storage.

Metadata and views#

• Video metadata (title, owner, renditions, status) lives in a sharded relational or wide-column database, cached heavily.
• View counts are huge write streams. Clients send events to Kafka; a stream processor aggregates them, so no row is incremented per view.
• Watch progress ("continue watching") is a small key-value write every few seconds per viewer.

Cost#

• Encode popular videos with newer codecs (AV1) to cut bandwidth by 30% or more; leave rarely watched videos in cheaper formats.
• Move old, unpopular originals to cold storage.
• Transcoding runs on spare or preemptible capacity, since jobs can simply retry.