YouTube System Design Interview: Design Video Streaming 2026

YouTube system design is the interview question where you design a service that accepts huge video uploads, converts each one into many streamable formats, and delivers them to millions of viewers with almost no buffering. The strongest answers treat it as a pipeline problem: resumable upload, an asynchronous transcoding DAG, segment packaging for HLS/DASH, and CDN delivery, with metadata and view counts handled by separate systems. If you can draw that path and defend the cost and latency trade-offs at each step, you have answered the question.

Key Takeaways

• Upload and playback are separate systems. Uploads are write-heavy, bursty and tolerant of minutes of delay. Playback is read-heavy, latency-sensitive and dominated by CDN egress.
• Transcoding is a DAG, not a single job. Split, encode per rendition in parallel, package, generate thumbnails, then publish. Each node retries independently.
• Bandwidth is the real cost driver. Egress dwarfs storage, so codec efficiency (VP9, AV1) and CDN hit rate move the bill more than database choices.
• Adaptive bitrate is client-driven. The server publishes a ladder of renditions in 2 to 6 second segments; the player picks one per segment based on throughput and buffer.
• View counts are a streaming aggregation problem. Log events, filter and deduplicate, batch increments, accept eventual consistency.

How Should You Scope the Requirements?

Scoping is the first thing graded, so spend about five minutes here and write the answers on the board. Interviewers want to see you cut the problem down before you design.

Functional requirements to propose:

1. Users upload videos (up to several GB, possibly hours long).
2. Users watch videos on web, mobile and TV with smooth quality switching.
3. Videos have metadata: title, description, channel, visibility, thumbnails.
4. Users search videos and see view counts.

Explicitly out of scope unless asked: recommendations, comments, live streaming, monetization and copyright matching. Say you would design these as separate services that consume the same upload events.

Non-functional requirements:

• Playback start time under roughly 2 seconds and rebuffering as rare as possible.
• High availability for playback; uploads can tolerate brief degradation.
• Durability: an accepted upload must never be lost.
• Processing latency: a video should be watchable within minutes of upload, with higher resolutions allowed to arrive later.

Back-of-the-envelope capacity math

According to figures published by Statista, more than 500 hours of video are uploaded to YouTube every minute. Use that as your anchor and label everything else as an assumption.

The punchline of this table is what you say out loud: egress is roughly 300 times larger than daily ingest. That single ratio justifies the CDN, the investment in better codecs, and the decision to keep the origin small. For a refresher on doing these estimates quickly, see our guide on how to ace the system design interview.

How Do Resumable Uploads Work?

A resumable upload splits a large file into chunks and lets the client continue from the last confirmed byte after a network failure. Without it, a 4 GB upload that drops at 95% starts over, which is unacceptable on mobile networks.

The flow most candidates should draw:

1. Initiate. Client calls POST /uploads with file size and metadata. The upload service creates an upload session, returns an upload_id and a session URL.
2. Send chunks. Client sends chunks (for example 8 to 16 MB each) with byte offsets. The service writes each chunk to object storage using multipart upload and records the committed offset.
3. Resume. After a failure, the client asks the server for the current offset and continues from there.
4. Complete. On the final chunk, the service assembles the object, verifies a checksum, marks the video UPLOADED, and publishes a video.uploaded event.

This is not hypothetical. Google's own YouTube Data API resumable upload guide describes the same session-based pattern, and the open tus protocol standardizes it over plain HTTP.

POST /uploads
Content-Type: application/json
{"filename": "talk.mp4", "size": 4294967296, "title": "Conference talk"}

201 Created
Location: /uploads/u_9f2c

PATCH /uploads/u_9f2c
Upload-Offset: 0
Content-Length: 16777216
<bytes>

204 No Content
Upload-Offset: 16777216

Two design details earn points. First, have clients upload directly to object storage with pre-signed URLs so your API servers never proxy gigabytes. Second, store upload session state (offset, checksum, expiry) in a small key-value store with a TTL, and garbage-collect abandoned multipart uploads, because orphaned parts quietly cost money.

What Does the Transcoding Pipeline Look Like?

The transcoding pipeline is a directed acyclic graph of tasks that turns one raw upload into every format a player might need. This is the heart of the YouTube system design, and drawing it as a DAG instead of a single "transcode" box is the clearest way to show depth.

                    video.uploaded event
                            |
                      [ Validate & Probe ]   (container, codec, duration, corrupt?)
                            |
                     [ Split into GOP-aligned chunks ]
                            |
     +-----------+----------+-----------+-----------+
     |           |          |           |           |
 [240p H.264][480p H.264][720p VP9][1080p VP9][1080p AV1]  ... per chunk, in parallel
     |           |          |           |           |
     +-----------+----------+-----------+-----------+
                            |
                [ Merge chunks per rendition ]
                            |
         +------------------+------------------+
         |                  |                  |
 [ Package CMAF segments ] [ Thumbnails ] [ Audio tracks / captions ]
         |                  |                  |
         +------------------+------------------+
                            |
           [ Write HLS + DASH manifests, publish ]
                            |
                 video.ready event -> metadata, search

Why split before encoding

Encoding a two-hour 4K file on one machine can take hours. Splitting at keyframe (GOP) boundaries lets hundreds of workers encode chunks at once, then a merge step stitches them. This is the standard way to cut processing latency from hours to minutes.

Orchestration

Use a workflow engine (Temporal, AWS Step Functions, or an in-house scheduler) that stores DAG state durably. Workers pull tasks from queues, and each task writes output to object storage with a deterministic key, so retries are idempotent. If one 480p chunk fails, you retry that chunk, not the whole video.

Prioritize the fast path

Publish low resolutions first. A 360p or 480p H.264 rendition can be ready in a minute or two, so the video becomes watchable while 4K and AV1 encodes keep running. Interviewers like hearing that "watchable" and "fully processed" are different states.

Encoding cost is a real constraint

Better codecs cut bandwidth but cost more compute. AV1 compresses more efficiently than VP9, which compresses better than H.264, but AV1 encoding is far more expensive. YouTube addressed this with custom hardware: in 2021 Google described its Argos video coding unit, a custom chip it said delivers many times better compute efficiency than conventional servers for video workloads. The interview lesson is a cost policy, not a chip.

A strong answer: encode everything in H.264 at upload, and trigger VP9 or AV1 encodes once a video crosses a view threshold. Most uploads get few views, so spending heavy compute on them wastes money.

How Should Storage and CDN Distribution Work?

Store media in object storage and serve it through a CDN, keeping the origin as a cache-miss backstop. Video segments are immutable static files, which makes them ideal for edge caching.

Storage layout and tiers

Use keys like videos/{video_id}/{rendition}/{segment_number}.m4s. Keep the raw source in cheaper cold storage after processing, since you only need it for re-encoding with new codecs. Video popularity follows a long tail, so tier storage by access:

• Hot: recent and trending videos, replicated widely, pre-positioned at edges.
• Warm: steady catalog content in standard object storage.
• Cold: rarely watched videos and source files in archival storage, with the trade-off that the first viewer may wait slightly longer.

CDN strategies compared

This is where senior candidates separate themselves. Each option trades cost against latency and control.

Real examples help here. Netflix runs Open Connect appliances inside ISP networks, and Google operates Google Global Cache nodes in ISPs for YouTube and other traffic. You do not need to build that in an interview; you need to explain why a company at this scale eventually would: transit bandwidth is the largest line item, and caching inside the ISP removes it.

Add an origin shield (a mid-tier cache between edges and origin) so a viral video does not trigger thousands of simultaneous origin fetches. That is the same thundering-herd idea you would discuss when you design a distributed cache.

How Does Adaptive Bitrate Streaming Work?

Adaptive bitrate streaming (ABR) is a technique where the video is encoded at several bitrates, split into short segments, and the player chooses which bitrate to fetch for each segment based on current network conditions. It is why YouTube drops to 480p on a train instead of freezing.

The server side publishes two things: the rendition ladder and a manifest. HLS uses an M3U8 playlist; MPEG-DASH uses an XML manifest (MPD). Using CMAF fragmented MP4 segments, one set of media files can serve both protocols.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.4d401e,mp4a.40.2"
360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/playlist.m3u8

Segment length is a latency vs efficiency trade-off

Apple's HLS authoring specification recommends a nominal segment duration of 6 seconds. Shorter segments let the player react faster and start sooner, but they mean more requests, more manifest churn and slightly worse compression because every segment starts with a keyframe.

Client logic

The player estimates throughput from recent segment downloads and watches buffer level. Throughput-based algorithms pick the highest bitrate below measured bandwidth; buffer-based algorithms (BOLA is the well-known example) choose bitrate from how full the buffer is. Mention that startup usually begins at a conservative rendition, then ramps up. That one sentence shows you understand why videos look blurry for the first second.

Signed URLs or tokens on manifests protect private and unlisted videos without making segments uncacheable.

How Do You Handle Metadata, Search and View Counts?

Metadata, search and view counts each have different consistency needs, so give each its own store.

Metadata

Video metadata (title, owner, visibility, status, rendition list) is relational and read-heavy. A sharded MySQL setup keyed by video_id works well, with a cache in front for hot videos. It is a strong detail that Vitess, the MySQL sharding system now used widely, was originally built at YouTube to scale exactly this layer.

CREATE TABLE videos (
  video_id     BIGINT PRIMARY KEY,
  channel_id   BIGINT NOT NULL,
  title        VARCHAR(100) NOT NULL,
  description  TEXT,
  visibility   ENUM('public','unlisted','private') NOT NULL,
  status       ENUM('uploading','processing','ready','failed') NOT NULL,
  duration_ms  INT,
  created_at   TIMESTAMP NOT NULL,
  INDEX idx_channel_created (channel_id, created_at)
);

Generate video_id with a distributed ID scheme, then encode it to a short public string, the same approach you would use to design a URL shortener.

Search

Consume video.ready and metadata-update events into a search index (Elasticsearch or OpenSearch in most answers). Index title, description, tags and captions, and rank with text relevance plus engagement signals. Search-as-you-type is its own problem; point to how you would design typeahead autocomplete instead of building it here.

View counts

A view count is a write-heavy counter where approximate, slightly delayed values are acceptable. Never run UPDATE videos SET views = views + 1 per view on a viral video.

1. The player sends a view event after a minimum watch threshold.
2. Events land in Kafka, partitioned by video_id.
3. A stream processor filters bots, deduplicates by session, and aggregates counts in short windows.
4. It writes batched increments to a counter store, using sharded counters for hot keys.
5. The read path caches the displayed count for a few seconds.

Abuse protection belongs here too: per-user and per-IP limits on counted views, similar to the techniques in our rate limiter design. The "subscribed channel uploaded a video" fan-out is a separate concern, closer to designing a notification system.

What Follow-Up Questions Do Interviewers Ask?

Expect two or three of these in the last 15 minutes. Have a one-paragraph answer ready for each.

Per-title encoding deserves a sentence: instead of one fixed bitrate ladder, analyze each video's complexity so a static lecture gets lower bitrates than a sports clip at the same visual quality. Netflix has written publicly about this approach, and it is a sharp answer to any cost question.

If you get asked about the home feed or recommendations, sketch the same fan-out reasoning you would use to design a news feed, then return to the video path.

How Do You Present This in 45 Minutes?

Time management decides this round more often than knowledge. A pacing plan that works:

1. 0 to 5 min: requirements and capacity math, ending on the egress-vs-ingest ratio.
2. 5 to 15 min: high-level diagram with upload service, object storage, transcoding DAG, CDN, metadata DB, search and analytics.
3. 15 to 35 min: deep dives on transcoding and ABR/CDN, since those carry the most signal.
4. 35 to 45 min: view counts, failures and follow-ups.

Video questions show up often at companies whose products depend on media, including the Google technical interview process and the Netflix technical interview process. Rehearse the diagram out loud until you can draw it in under five minutes; our guide on how to practice system design interviews covers a repeatable routine.