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

High-Level Architecture

Detailed Architecture (Read vs Write Paths)

Workshop note · added for the website’s common reading format

For Video Streaming, define contracts around the boundary components: Creator client, Upload service, Transcode workers. Specify authentication, request identity, versioning, pagination or streaming semantics, timeouts, and retry behavior. Name which operations are idempotent and how callers discover an uncertain outcome.

The source discusses these contracts within its subsystem walkthroughs rather than as a standalone endpoint catalog. The examples in this article are design exercises, not published service APIs.

Data Model

Video Metadata (MySQL / Vitess)

View Counts at Scale

Workshop note · added for the website’s common reading format

Use the detailed source walkthroughs in this article to examine Video Streaming at this layer. State the requirement, propose the smallest component that satisfies it, and make its cost and failure mode explicit.

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

Workshop note · added for the website’s common reading format

Walk through three failure moments in Video Streaming: a request times out before its result is known; a dependency becomes slow rather than unavailable; and a process restarts after committing state but before acknowledging it.

For each case, name the authoritative record, define a safe retry, cap resource usage, and describe what the caller sees. Playback telemetry should help detect and contain the problem: Optimize user-visible startup delay, buffering, and cost rather than raw throughput alone.

Tradeoffs & Design Decisions Summary

Workshop note · added for the website’s common reading format

Optimize user-visible startup delay, buffering, and cost rather than raw throughput alone.

Set service-level objectives for the user-visible path, then map its dependencies. Define bounded retries with jitter, deadlines, and backpressure. Keep a degraded mode that protects authoritative state, and test recovery instead of treating replication as a backup.

For Video Streaming, pay special attention to Object storage, CDN when deciding failure domains and recovery procedures.

Production Architecture

Workshop note · added for the website’s common reading format

Rebuild Video Streaming from memory, then change one assumption: ten times more traffic, a new region, or a stricter consistency requirement. Which component must change first—and which does not?

Compare Transcode workers with the same boundary in a related design. Write down one alternative you rejected, what it would simplify, and when you would choose it instead. Follow the source link at the end of this article to explore the original document.

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."