Video Streaming

Problem Statement & Requirements

Functional Requirements

• Upload videos -- creators upload video files (up to 10 GB), system processes and stores them
• Stream videos -- viewers watch videos with smooth playback, adaptive quality
• Search & discovery -- search by title/tags, homepage recommendations, trending
• Video metadata -- title, description, tags, thumbnails, view count, likes/dislikes
• Comments -- threaded comments on videos
• Subscriptions / channels -- users subscribe to creators, see new uploads in feed
• Watch history & resume -- track progress, resume from where user left off
• Live streaming (brief mention) -- real-time broadcast with minimal delay

Non-Functional Requirements

• Low startup latency -- video begins playing within 2 seconds
• No buffering -- adaptive bitrate prevents rebuffering on bandwidth changes
• High availability -- 99.99% uptime for playback (upload can tolerate brief outages)
• Global reach -- low latency worldwide via CDN
• Scalability -- 1B+ DAU, 500+ hours of video uploaded per minute
• Cost efficiency -- storage and bandwidth are the dominant costs

Out of Scope

• Monetization / ads system (that's a separate design)
• Creator analytics dashboard
• Copyright detection (Content ID) -- mentioned briefly
• Short-form video (TikTok-style) -- similar but different optimization profile

Scale Estimations

Users & Content

Storage

Bandwidth

Transcoding

This first layer defines the system boundary. The next chapters add application logic and data dependencies. After examining the request paths and tradeoffs, we will add operational safeguards and bring the complete architecture together.

Creating an upload should return an upload ID and a resumable transfer contract. Playback needs a different contract: authorization, a manifest, and URLs for the available segments. A client polling processing status must be able to distinguish uploading, processing, ready, and failed instead of guessing readiness from the presence of an object.

Data Model

Video Metadata (MySQL / Vitess)

View Counts at Scale

Do not make viewers wait for the original video to finish every processing task. Define which renditions are sufficient for initial playback and publish a manifest only when its referenced segments are available. Adaptive playback chooses among prepared renditions; it does not ask the origin to re-encode each segment for each viewer.

Video Upload Flow

Multipart Upload for Large Files

Transcoding Pipeline -- The Heart of the System

Why Transcode?

Transcoding Output Matrix

Transcoding Architecture

Parallel Transcoding Strategy

Video Playback Flow

Cost Optimization

Adaptive Bitrate Streaming (ABR)

How ABR Works

HLS Manifest Example

ABR Algorithm (Client-Side)

CDN Architecture

Multi-Tier CDN Strategy

CDN Content Routing

Video Player Architecture

Recommendation Engine (Brief)

Live Streaming (Brief Overview)

Content Moderation & Copyright

A creator may delete a video while cached segments remain at the edge. Decide how authorization expiry and cache invalidation limit continued access. Also handle partial processing failure: a broken high-resolution rendition need not make healthy lower-resolution versions disappear, but the manifest must not advertise missing segments.

Tradeoffs & Design Decisions Summary

Make transcoding jobs repeatable using stable input versions and deterministic output locations. A worker can crash after writing a segment but before reporting success. Validate existing output on retry, and publish readiness atomically enough that players never receive a manifest pointing to unfinished media.

High-Level Architecture

Detailed Architecture (Read vs Write Paths)

Production Architecture

Compare a recorded lecture with a live sports match. The lecture favors reuse and efficient delivery; the match adds an end-to-end freshness budget. Follow where latency accumulates—in capture, encoding, packaging, delivery, and the player’s buffer—before choosing which safety margin to reduce.

Interview Tips

1. Separate upload from playback -- These are completely different systems. "Let me design the write path (upload + transcode) first, then the read path (streaming)." This structures your answer clearly.

2. Transcoding is the centerpiece -- Spend the most time here. Explain why you need multiple resolutions + codecs, parallel segment encoding, and the output matrix.

3. ABR is what makes streaming work -- "The player dynamically switches quality based on bandwidth. This is why Netflix doesn't buffer on your phone even on a spotty connection." Draw the segment timeline with quality switches.

4. CDN is critical for scale -- "1 Petabit/s of egress bandwidth. No origin server handles that. You need a multi-tier CDN with edge PoPs worldwide." Mention Netflix Open Connect if you know it.

5. View counts are a distributed systems problem -- "5B views/day. You can't UPDATE a SQL row on every view. Buffer in Kafka, aggregate in Redis, flush to DB." This shows you think about practical bottlenecks.

6. Presigned URLs for upload -- "The video file goes directly from client to S3. Our API servers never touch the bytes." Simple but important.

7. Cost awareness differentiates senior candidates -- "Storage is the biggest cost. Tiered storage, lazy transcoding, and AV1 codec migration are how YouTube/Netflix keep costs manageable at exabyte scale."

8. HLS manifest is worth showing -- Write out the master playlist. It's concrete, shows you know the actual protocol, and takes 30 seconds to draw.

9. Don't forget startup latency -- "Start with lowest quality for the first 2 segments, then ramp up. This gives sub-2-second time-to-first-frame."

10. Mention live streaming briefly -- "Live is similar but uses RTMP for ingest and LL-HLS for playback with 2-6 second segments. The key difference is real-time transcoding instead of batch."