Designing YouTube / Netflix

Video systems are heavyweight. A single user upload can trigger thousands of CPU hours of processing. The core challenge is managing this asynchronous workflow efficiently.

1. Requirements

Functional

• Upload: Users upload raw video files (MOV, AVI, MKV).
• View: Users stream videos with zero buffering.
• Quality: Support 360p, 480p, 720p, 1080p, 4K.

Non-Functional

• Reliability: Uploads must not be lost.
• Scalability: Handle variable spikes (e.g., Viral events).
• Latency: Processing shouldn't take forever, but it's not strictly real-time.

2. API Design

Uploading a 50GB File

You cannot use a simple POST /upload. HTTP times out. Solution: Pre-signed URLs (S3) with Resumable Uploads.

1. Client: POST /initiate-upload.
2. Server: Returns a session ID and a chunk offset 0.
3. Client: Uploads chunk 1.
4. Client: Connection dies? Client retries from offset X.

3. The Transcoding Pipeline (DAG)

We don't just convert format A to format B. We need thumbnails, captions, copyright checks, and AI content moderation. We model this as a Directed Acyclic Graph (DAG).

The Components

1. Inspector: Extracts metadata (resolution, codec).
2. Splitter: Breaks video into 10-minute chunks.
3. Transcoder: Parallel workers convert chunks to H.264 / VP9.
4. Thumbnailer: Grabs frames at timestamp t.
5. Joiner: Stitches processed chunks back (if necessary for storage, though streaming uses chunks).

Orchestration

• Tech: AWS Step Functions / Airflow / Temporal.io.
• Why?: If the "Copyright Check" fails, we stop the "4K Transcode" immediately to save money.

4. Adaptive Bitrate Streaming (ABR)

You don't stream one big .mp4 file anymore. We use HLS (HTTP Live Streaming) or MPEG-DASH.

How it works

1. Break it up: Video is sliced into 4-second .ts (Transport Stream) segments.
2. Variants: Each 4-second segment is encoded in multiple qualities:
   • segment_001_1080p.ts (High Bitrate)
   • segment_001_360p.ts (Low Bitrate)
3. Manifest File (.m3u8): A text file listing all available variants.

The Player Logic:

• Client downloads Manifest.
• Client detects bandwidth (e.g., 4G is slow).
• Client requests segment_001_360p.ts.
• Bandwidth improves to 5G?
• Client requests segment_002_1080p.ts.
• Result: Seamless quality switching without buffering.

5. Storage & Optimization

Optimization: GOP Alignment

When splitting video for parallel processing, you must split at Keyframes (I-Frames). If you split in the middle of a "P-Frame" (which relies on previous frames data), the video will glitch.

Storage Tiers

• Raw Video: Store in Cold Storage (AWS Glacier). We rarely need the raw file again, but we keep it for future re-encoding (e.g., when VR/8K comes out).
• Encoded Segments: Store in Hot Storage (S3 Standard) -> Pushed to CDN.

6. Content Delivery Network (CDN)

• Popular Content (Taylor Swift video): Cache at the Edge (ISP level). 99% cache hit ratio.
• Long Tail (Unwatched vlogs): Fetch from Origin (S3) on demand.

7. Back-of-Envelope: What Scale Are We Designing For?

Interviewers love this part, and the numbers justify every architectural choice above. Assume YouTube-like inputs: 500 hours of video uploaded per minute.

Uploads:     500 hrs/min ≈ 30,000 hrs/hour of raw footage
Transcoding: each hour of video → 5-8 output renditions
             ⇒ 150,000-240,000 hours of encoding output per hour
Compute:     encoding runs slower than realtime on CPU for high quality
             ⇒ hundreds of thousands of cores busy 24/7
Storage:     1 hr of 1080p H.264 ≈ 3-5 GB across renditions
             ⇒ multiple petabytes of new storage per day

Two conclusions fall out immediately. First, transcoding compute dwarfs serving compute — this is why the DAG/chunking design matters: splitting a video into 200 chunks turns a 4-hour sequential encode into a 2-minute parallel one across 200 workers. Second, storage economics dominate: this is why the read path leans so heavily on the CDN and why cold raw masters go to Glacier.

The Spot Instance Trick

Because chunked transcoding jobs are small, idempotent, and retryable, they are the perfect workload for preemptible/spot instances at 60–90% discount. A worker gets reclaimed mid-chunk? The orchestrator re-queues that chunk elsewhere. Large video platforms run the bulk of their encoding fleets this way — resilience patterns (queues, retries, idempotency) convert directly into a massive cost advantage.

8. Codec Strategy: Not Every Video Deserves VP9

Encoding cost and delivery cost pull in opposite directions:

Spending 10x the compute on AV1 only pays off if enough people watch the video to recoup the bandwidth savings. So platforms tier by popularity: every upload gets a fast H.264 ladder (video is watchable in minutes); videos crossing view thresholds are re-encoded into VP9, then AV1. The cold-stored raw master is what makes this retroactive upgrading possible — the same reason 10-year-old videos could be re-rendered when better codecs shipped.

9. The Metadata Plane

The video bytes are only half the system. Every play needs metadata: title, channel, view count, like count, and the manifest URL. This plane has a completely different profile — millions of tiny reads per second, heavily cacheable, with a few hot keys (viral videos) that can melt a single database partition.

• View counting is a classic write-hotspot: a viral video receives tens of thousands of increments per second. Solution: buffer counts in memory/Redis per region, flush aggregates to the database periodically — nobody needs a view counter accurate to the second. The same technique appears in Top-K Heavy Hitters.
• Manifest personalization: the returned rendition list can differ by device, region (codec licensing), and network — the manifest endpoint is an API, not a static file.
• Hot-key caching: viral video metadata is served almost entirely from cache; see Caching Strategies.

Common Interview Follow-Ups

• "How do you make a just-uploaded video playable fast?" Priority lanes in the DAG: encode the 360p rendition first and publish a minimal manifest — the video is live in under a minute while the full ladder finishes in the background.
• "What about live streaming?" Same HLS/DASH delivery, but the pipeline becomes real-time: no splitter, a fixed low-latency encode ladder, segments published as produced, and 2-6 second end-to-end latency targets replacing throughput optimization.
• "How do you deduplicate re-uploads?" Content fingerprinting (perceptual hashing) at ingest — matching a fingerprint database short-circuits the entire pipeline and handles copyright automatically.

Summary

1. Upload: Resumable upload to Object Storage (S3).
2. Process: DAG Workflow using parallel workers (Split -> Transcode -> Merge), prioritized so a watchable rendition ships in minutes.
3. Delivery: HLS/DASH Adaptive Streaming via CDN, with codec tiers matched to popularity.
4. Metadata: A separate read-heavy plane with buffered counters and aggressive caching.

Related Concepts

• System Design: Netflix Streaming
• CDN — Content Delivery Networks
• Object Storage
• Message Queues