Design YouTube / Netflix (Video Streaming) — System Design

🟠 High-Level Design · Senior → 🔴 the video pipeline deep dive

"Design YouTube / Netflix / a video streaming service." This one is exciting because video is huge — a single upload can be gigabytes, and it must play smoothly for billions of viewers on everything from a phone on 3G to a 4K TV. The magic is in two pieces most people miss: the transcoding pipeline and adaptive streaming. Let's design it end to end.

Step 1 — Requirements

• Functional: upload a video; watch a video; it plays smoothly across devices and network speeds; search/metadata; view counts.
• Non-functional: massive storage and bandwidth, extremely read/stream-heavy (far more watching than uploading), low buffering, and highly available globally.

Step 2 — The upload & processing pipeline (the interesting half)

🔴 When you upload a video, a lot happens asynchronously before it's watchable:

1. Chunked upload: the video uploads in pieces to object storage (resumable if the connection drops), often via a pre-signed URL so bytes go straight to storage, not through your servers.
2. Transcoding: a job is queued; workers transcode the raw file into many versions — different resolutions (1080p, 720p, 480p, 240p) and formats/codecs — and split each into small segments. This is CPU-heavy and massively parallel.
3. Distribute: processed segments are pushed to a CDN so they're cached close to viewers worldwide.
4. Publish: metadata is updated and the video becomes watchable. (This is why a fresh upload sometimes says "HD processing…"—transcoding is still running.)

Step 3 — Adaptive bitrate streaming (why it never buffers)

🔴 The key to smooth playback: video isn't one big file, it's chopped into small segments (a few seconds each) at every quality level, described by a manifest (HLS or DASH). The player downloads segments one at a time and adapts: on a fast connection it grabs 1080p segments; if bandwidth drops mid-video, it seamlessly switches to 480p for the next segment. That's adaptive bitrate streaming — the same mechanism Netflix and YouTube use to avoid buffering. Explaining "segment the video per quality + a manifest + the player adapts per segment" is the standout answer here.

Step 4 — Serving at scale

🟠 Streaming is bandwidth-dominated and read-heavy, so the CDN does almost all the work: popular videos are cached at edge servers near viewers, so the vast majority of bytes never touch your origin. This is exactly the CDN's superpower — offload the origin and cut latency — applied to petabytes of video. Your own servers mostly handle metadata and the manifest; the heavy segments come from the edge.

Step 5 — Metadata & data model

videos:   video_id, user_id, title, description, status,
          duration, created_at, cdn_manifest_url
video_files: video_id, resolution, format, storage_url  (the transcoded versions)
metadata DB: relational for video info; the actual media in object storage + CDN

Video files live in object storage/CDN; the database holds only lightweight metadata and the manifest URL — never the video bytes (store the URL, not the blob).

Step 6 — View counts & the read-heavy extras

🔴 View counts at YouTube scale can't be a synchronous UPDATE per view — that would hammer the DB. Instead, views are streamed as events (to Kafka) and aggregated asynchronously — eventually consistent counts are fine (a view count lagging by seconds is acceptable). Recommendations, search, and comments are separate services layered on the same metadata.

The interview-ready walkthrough

"Uploads go chunked straight to object storage, then an async transcoding pipeline (queue + workers) produces many resolutions and splits each into segments, which are pushed to a CDN. Playback uses adaptive bitrate streaming (HLS/DASH): the player picks segment quality per few seconds based on bandwidth, so it never buffers. The CDN serves the heavy bytes, my origin serves lightweight metadata and manifests from a relational DB (media as URLs, not blobs), and view counts are aggregated asynchronously via a stream. It's fundamentally storage + transcoding + CDN." That's the full picture interviewers want."

What to read next

• Object Storage (S3) · CDN Explained — the two pillars of video
• Message Queues & Kafka — the transcoding & view-count pipelines
• Design Dropbox — another big-file / storage system
• ← The complete System Design guide (hub)

← Design a key-value store · Design Uber →