YouTube System Design Interview Guide

Video streaming comes up in FAANG interviews because it's genuinely hard in multiple directions at once: you're dealing with large binary assets, async processing pipelines, global delivery, and a client-side protocol most engineers have never had to think about. The "store files and serve them" framing candidates arrive with gets demolished pretty quickly.

Where level shows up most clearly: junior candidates know video needs different quality options; senior candidates understand why the file isn't served as a single blob and what ABR actually means in practice; staff and above think about the economics, CDN egress is a different cost category from database reads, and the architecture reflects that.

Before drawing anything, separate the two subsystems: the upload and transcoding path (write-heavy, async, latency-tolerant) and the playback path (read-heavy, synchronous, latency-critical). Most design mistakes come from conflating them.

Functional requirements

Non-functional requirements

Video systems are unusual in that storage and bandwidth dominate costs rather than compute or QPS. A single 1080p minute of video compresses to roughly 150 MB at H.264. Encoding all 5 quality tiers (360p through 4K) multiplies that by ~5.9×, 4K alone is roughly 4× the size of 1080p, and the lower tiers (720p, 480p, 360p) add another ~0.9× combined. CDN egress, not storage, is usually the biggest line item: a popular video served to 1M viewers costs more to deliver than to store.

A video streaming platform separates two fundamentally different subsystems: the upload and transcoding path (write-heavy, asynchronous, latency-tolerant) and the playback path (read-heavy, synchronous, latency-critical). Producers upload raw video files; these are asynchronously encoded into multiple quality variants and distributed to CDN edge nodes. Viewers stream encoded segments directly from the nearest CDN edge, with the player selecting quality adaptively based on available bandwidth.

Upload API orchestrates uploads without ever touching the video bytes. It issues pre-signed S3 multipart upload URLs to the client; the client uploads each chunk directly to S3, bypassing the API server entirely. Once the client calls /upload/complete with the per-chunk ETags, the API calls S3's CompleteMultipartUpload and publishes a transcoding job to the queue. This keeps the Upload API stateless and prevents it from becoming a bandwidth bottleneck, S3 absorbs all the byte transfer load.

Object Store holds two kinds of data: raw uploads awaiting transcoding, and the encoded segment files that are the actual playback artefacts. These are structurally separate prefixes within the same store. The raw bucket is ephemeral (files may be lifecycle-deleted after 30 days); the segments bucket is permanent and must be globally durable.

Message Queue (a durable log like Kafka) decouples the upload API from the transcoding workers. Without this, upload latency becomes coupled to transcoding capacity, a transcoding backlog would block new uploads. The queue also provides retry semantics: if a transcoding job fails, the message is not acknowledged and gets re-delivered.

Transcoding Workers consume jobs from the queue, pull raw video from the object store, run FFmpeg (or a custom encoder), and write the output segments back to the object store. CPU-bound and embarrassingly parallel, during peak upload hours you scale out the fleet; overnight you scale it back. Workers are stateless, so there's no coordination overhead.

Metadata DB stores video metadata (title, description, uploader, duration, manifest URL, processing status). This is a relational workload, a SQL database (PostgreSQL) is appropriate. The metadata record is created at upload time with status processing and updated to ready once transcoding completes.

CDN Edge (a content delivery network like Cloudflare or Akamai) serves video segments from points of presence near the viewer. The CDN pulls segments from the object store on first request and caches them at the edge. For popular videos, 95%+ of requests are served entirely from edge cache without touching origin.

API Gateway handles the viewer's two non-video requests: fetching video metadata and fetching the manifest file that describes available qualities and segment URLs. These are tiny JSON payloads, the gateway routes to the metadata service, which hits the database (or cache) and returns within milliseconds.

Architectural rationale

Real-world comparison

Adaptive bitrate (ABR) streaming is a video delivery technique where the source video is cut into short segments (typically 4–6 seconds) and encoded at multiple quality levels — for example 360p, 720p, 1080p, and 4K. A manifest file (HLS .m3u8 or DASH .mpd) lists all available quality variants and their segment URLs. The client player measures current network bandwidth and buffer fill, then requests each segment at the highest quality it can sustain without rebuffering. The server’s job is to make all versions available; the adaptation logic lives entirely in the player.

Most distributed systems serve one canonical response to a request. Video streaming serves dozens of versions of the same content, the client picks which one to fetch next, segment by segment, based on what its network can handle right now. The server's job is to make all the versions available; the adaptation logic lives entirely in the player.

The mechanism: cut the video into short segments (4–6 seconds each), encode each segment at multiple quality levels, and publish a manifest listing all the options. The client downloads the next segment at whatever quality its measured throughput can sustain. Because it's only committing 4–6 seconds ahead, it can step down quality quickly when the network degrades, without making the viewer wait for a full rebuffer.

The two standard protocols: HLS and MPEG-DASH

Our choice for this design is HLS with fMP4 segments. HLS offers the broadest device compatibility (including all Apple devices) and fMP4 segments are compatible with most DASH players, giving us the option to serve both protocols from the same segment files. For interview purposes, either choice is fine, the important thing is explaining the tradeoff.

POST /videos/upload/init, Initiate chunked upload

// Request
{
  "filename": "vacation.mp4",
  "file_size_bytes": 2147483648,  // 2 GB
  "content_type": "video/mp4",
  "title": "Summer Vacation 2025",
  "description": "..."
}

// Response 201 Created
{
  "upload_id": "upl_8f3k2j9...",
  "video_id": "vid_4x2k9...",
  "chunk_urls": [           // pre-signed S3 multipart URLs
    { "part_number": 1, "url": "https://s3.../..." },
    // ...
  ],
  "chunk_size_bytes": 5242880  // 5 MB chunks
}

The upload API returns pre-signed S3 multipart upload URLs. The client uploads each chunk directly to S3 , the upload API server never touches the video bytes, only the metadata. This prevents the API server from becoming a bandwidth bottleneck and offloads the heavy lifting to S3's durable storage layer.

POST /videos/upload/complete, Finalize and trigger transcoding

// Request
{
  "upload_id": "upl_8f3k2j9...",
  "parts": [
    { "part_number": 1, "etag": "\"abc123\"" },
    // ...
  ]
}

// Response 202 Accepted
{
  "video_id": "vid_4x2k9...",
  "status": "processing",
  "estimated_ready_at": "2025-06-01T12:05:00Z"
}

GET /videos/:id, Fetch video metadata and manifest

// Response 200 OK
{
  "video_id": "vid_4x2k9...",
  "title": "Summer Vacation 2025",
  "uploader": { "id": "usr_...", "name": "Alice" },
  "duration_seconds": 342,
  "view_count": 18420,
  "status": "ready",           // or "processing" | "failed"
  "manifest_url": "https://cdn.example.com/videos/vid_4x2k9/master.m3u8",
  "thumbnail_url": "https://cdn.example.com/thumbs/vid_4x2k9.jpg"
}

Upload flow

The latency NFR for uploads is relaxed, users expect processing to take minutes, not milliseconds. The primary requirements are reliability (no data loss) and resumability (a dropped connection should not require re-uploading 2 GB). These requirements together drive the multipart upload pattern, where each chunk is independently acknowledged before the next is sent.

Playback flow

The playback latency NFR (<2s to first frame, from §2) drives the key design decision here: the manifest and first segment must be available from CDN edge before the player starts buffering. The manifest file is tiny (~1 KB) but is fetched on every play, it goes through the API gateway, which checks metadata DB for the manifest URL and returns it. The segments themselves are fetched directly by the player from the CDN edge URL embedded in the manifest.

The video platform has three distinct data domains with very different access patterns. The access patterns are worth looking at first, they're what determine the schema, not the other way around.

Two things stand out from this table. First, the dominant read pattern is a point lookup by video_id, this is extremely cache-friendly and drives the Redis metadata cache in §8. Second, view count increments are so frequent that they cannot go directly to the primary database without creating a hot-spot on popular video rows; they need their own buffered write path.

Schema

-- Core video record
CREATE TABLE videos (
  video_id      VARCHAR(16)  PRIMARY KEY,
  uploader_id   VARCHAR(16)  NOT NULL REFERENCES users(user_id),
  title         TEXT         NOT NULL,
  description   TEXT,
  duration_sec  INTEGER,
  status        VARCHAR(16)  NOT NULL DEFAULT 'processing',
                             -- 'processing' | 'ready' | 'failed'
  manifest_url  TEXT,        -- null until transcoding completes
  thumbnail_url TEXT,
  created_at    TIMESTAMPTZ  NOT NULL DEFAULT NOW()
);

-- View counts live separately, write-heavy, eventually consistent
-- Managed by counter service; flushed here periodically from Redis
CREATE TABLE video_stats (
  video_id      VARCHAR(16)  PRIMARY KEY REFERENCES videos(video_id),
  view_count    BIGINT       NOT NULL DEFAULT 0,
  like_count    BIGINT       NOT NULL DEFAULT 0,
  updated_at    TIMESTAMPTZ  NOT NULL DEFAULT NOW()
);

-- Indexes
CREATE INDEX idx_videos_uploader ON videos(uploader_id, created_at DESC);
CREATE INDEX idx_videos_status   ON videos(status) WHERE status = 'processing';

Video streaming uses three distinct caching layers: a CDN edge cache (stores immutable video segments close to viewers, TTL 7 days), a Redis metadata cache (stores serialized video JSON per video_id, handles ~1M QPS, TTL 10 minutes), and a Redis counter buffer (accumulates view and like increments in memory, flushed to PostgreSQL every 60 seconds). The CDN layer is what makes the economics of video streaming viable — at peak, 95%+ of segment requests are served from edge cache without touching origin.

A video uploaded once might be watched ten million times. That read/write ratio shapes every caching decision, and at this scale, caching isn't optional, it's what makes the cost model work at all. There are three distinct layers, each addressing a different part of the request path.

-- Atomically capture and reset a counter.
-- Returns the previous value as a string, or nil if the key didn't exist
-- (i.e. no views since the last flush). Caller must handle nil.
local val = redis.call('GET', KEYS[1])
if val then redis.call('SET', KEYS[1], '0') end
return val  -- nil means delta = 0; skip the DB write

The following scalability problems don't all arise at the same time. A service at 1M daily users looks different from one at 100M. These are the problems that emerge as you scale, roughly in the order they bite you.

Classic interview probes