Design YouTube
Problem
Design a video sharing platform like YouTube. Creators upload videos up to several hours long, and the platform processes each upload into multiple resolutions so viewers on any device and connection can watch smoothly. Viewers stream videos on demand with fast start and minimal buffering, and see view counts, likes, and comments. Creators upload 500 hours of video every minute, and viewers watch 1 billion hours of video per day worldwide.
- What is the maximum upload size and duration?
- Which output formats and resolutions do we need, from 144p up to 4K?
- How quickly must a video be watchable after upload: minutes, or is an hour acceptable for higher resolutions?
- Is live streaming in scope, or only on-demand video?
- Do view counts need to be exact and real time, or approximately correct within minutes?
- Are recommendations and search in scope, or only upload and playback?
Items in bold are existing requirements. The rest are suggestions. Confirm with the interviewer whether they are relevant first.
- Upload videos, including very large files, with resume after interruption.
- Transcode each video into several resolutions and bitrates.
- Stream videos on demand with adaptive quality.
- Show view counts, likes, and comments.
- Generate thumbnails and let creators edit title, description, and visibility.
- Block copyrighted or policy-violating content before publishing.
Items in bold are existing requirements. The rest are suggestions. Confirm with the interviewer whether they are relevant first.
- Ingest 500 hours of video per minute; at roughly 2 GB per source hour, that is about 1 TB of uploads per minute.
- Serve 1 billion watch hours per day; that is about 42 million concurrent viewers on average, and at 3 Mbps each about 125 Tbps of egress, higher at evening peaks.
- Playback starts within 2 seconds, with rebuffering on fewer than 1% of sessions.
- A video becomes watchable at standard quality within a few minutes of upload finishing.
- Storage grows by about 1.4 PB per day of source files, and the transcoded renditions add a similar amount again, which is why rarely watched renditions move to cold storage.
- Uploaded videos are never lost; playback availability of 99.99%.
Creators upload through resumable chunked uploads directly to object storage, and an upload event starts a transcoding workflow that splits the source into short segments, encodes them in parallel into a ladder of resolutions, and writes HLS and DASH segments plus manifests. Viewers fetch a manifest from the playback service and pull segments from a CDN, whose edge caches serve the vast majority of bytes, while the player picks the bitrate per segment based on measured throughput. View events stream into an aggregation pipeline that updates approximate counts every few seconds.
Loading diagram...
Upload. The creator's client calls POST /videos with title and file size. The upload service creates a video record in uploading state and returns a resumable upload session URL. The client sends the file in 8 MB chunks; if the connection drops, it asks for the last committed offset and continues from there. When the last chunk lands, the service marks the video processing and publishes an upload complete event.
Transcode. The orchestrator splits the source into segments of a few seconds at keyframes, then fans out encoding tasks: each segment times each rendition (for example 240p, 360p, 480p, 720p, 1080p, 4K) in H.264 and a newer codec such as VP9 or AV1 for popular videos. Workers write encoded segments to rendition storage. When the lower resolutions finish, the orchestrator writes manifests and sets the video to ready, and higher resolutions are added as they complete.
Watch. The player calls GET /videos/:id/play, which checks visibility and region rules and returns the manifest URL on the CDN, signed and short-lived. The player loads the manifest, starts with a low bitrate segment for fast start, measures download speed, and steps up or down the ladder segment by segment. Popular segments are served from edge caches; misses go to regional mid-tier caches and finally to rendition storage.
Count views. The player sends a view event after a qualifying watch time. Events flow into a stream, are deduplicated and checked for fraud, aggregated per video in short windows, and added to the stored count.
Receives large uploads reliably and creates the video record.
- Resumable upload protocol (such as the tus protocol, or chunked uploads to presigned URLs on S3 or GCS multipart upload).
API
POST /videoswith{ title, sizeBytes, mimeType }returns{ videoId, uploadUrl }.PUT {uploadUrl}with aContent-Rangeheader uploads a chunk.GET /videos/:id/statusreturnsuploading,processing,ready, orfailed.
Tradeoffs
Sending bytes straight to object storage with presigned URLs keeps application servers out of the data path, which would otherwise need to proxy about 1 TB per minute. Chunked, resumable uploads matter because multi-gigabyte files over mobile networks rarely finish in one attempt.
Converts each source file into an adaptive bitrate ladder of streamable segments.
- A workflow engine (such as Temporal) for orchestration, and FFmpeg-based workers on a large autoscaled pool, with GPU or dedicated video encoding hardware for the most expensive codecs.
Diagram
Loading diagram...
Scalability
Splitting into segments turns a one-hour encode into hundreds of small tasks that finish in minutes on many machines. The task queue is prioritized: low resolutions and partner channels first, expensive codecs for older videos only after they prove popular, since most uploads get few views.
Tradeoffs
Encoding every video in every codec would waste enormous compute on videos nobody watches. Encoding the efficient but expensive codecs only for popular videos spends compute where it saves the most bandwidth. Per-segment parallelism adds complexity (consistent keyframes, stitching), but the latency win is essential at this upload rate.
Stores video records, channel data, and engagement counts.
- Sharded MySQL (for example via Vitess) for video and channel records, with a cache tier in front.
Data Model
videos:video_id,channel_id,title,description,status,duration_s,visibility,manifest_path,created_at.video_stats:video_id,view_count,like_count,comment_count,updated_at.comments:video_id(partition key),created_at,comment_id,user_id,text, in a wide-column store.
Scalability
Metadata reads are heavy and highly cacheable; video pages read through a cache with short TTLs. Stats are kept in a separate table so frequent count updates do not contend with metadata edits.
Tradeoffs
A relational store keeps channel ownership and visibility consistent, and its read load is absorbed by caches. Comments have a much higher write rate and simple access patterns, so they live in a wide-column store.
Delivers video segments close to viewers with adaptive bitrate.
- A multi-tier CDN: edge caches inside ISP networks, regional mid-tier caches, and origin rendition storage.
- HLS and DASH manifests with segments of 2 to 6 seconds.
Scalability
Video popularity is extremely skewed, so edge caches holding the most watched few percent of segments serve over 90% of bytes. Placing cache servers inside large ISPs cuts transit costs and latency. New popular uploads are pushed to edges proactively.
Tradeoffs
Short segments let the player adapt quickly to bandwidth changes but add request overhead; a few seconds per segment balances both. Signed manifest URLs protect private and region-restricted videos without authenticating every segment request at the edge.
Aggregates view events into counts.
- Kafka for events and a stream processor such as Flink for windowed aggregation.
Scalability
Billions of events per day are partitioned by video ID, aggregated in memory for a few seconds, and written as one increment per video per window, so even a viral video causes a few writes per minute instead of thousands per second.
Tradeoffs
Counts are approximate in real time and are corrected later by a batch job that removes fraudulent and duplicate views. Exact synchronous counting would turn every view into a contended write on one row.