How Would You Design YouTube?
Learn how to design a video platform like YouTube: transcoding pipelines, adaptive bitrate streaming, CDN caching, and metadata scaling.
Expected Interview Answer
Designing YouTube means splitting the system into an upload/transcoding pipeline that converts raw video into multiple bitrates and resolutions, a metadata service backed by a relational or wide-column store, and a globally distributed CDN that serves adaptive-bitrate video segments close to each viewer.
On upload, the raw file lands in blob storage and a transcoding pipeline (often a chain of workers coordinated by a queue) produces multiple resolutions and bitrates using codecs like H.264 or AV1, then packages them into HLS or DASH segments. Metadata (titles, descriptions, view counts, comments) lives in a database optimized for the access pattern — view counts in particular need write-heavy, eventually consistent counters rather than a strongly consistent row update on every view. Playback pulls manifest files describing available bitrates, and the client adaptively switches quality based on measured bandwidth, while a CDN caches segments at edge locations so most requests never reach the origin. Recommendations and search sit as separate services fed by an event stream of watch history, decoupled from the core upload/serve path so they can scale and iterate independently.
- Adaptive bitrate streaming keeps playback smooth across varying network conditions
- CDN edge caching cuts origin load and latency for the vast majority of views
- Decoupled transcoding pipeline lets uploads succeed even while processing continues asynchronously
- Separating recommendations/search from the serving path allows independent scaling and experimentation
AI Mentor Explanation
Designing YouTube is like a cricket board turning a single raw match feed into several broadcast versions — full HD for the main channel, a lower-bitrate feed for mobile data users, and a highlights package — all produced by a chain of production crews working after the live action ends. Viewers connect to whichever feed their connection can handle, switching down to the lower-bitrate version automatically if their signal weakens mid-over, without the broadcast stopping. Regional relay towers rebroadcast the signal locally instead of every household pulling straight from the stadium, cutting congestion at the source. That layered production-plus-local-relay model is exactly how a video platform serves the same upload to millions of varied viewers efficiently.
Step-by-Step Explanation
Step 1
Upload and store raw video
The client uploads the file to blob storage (e.g., S3-compatible object store) and a job is enqueued for processing.
Step 2
Transcode into multiple renditions
Worker fleets convert the raw file into several resolutions/bitrates and package them as HLS/DASH segments.
Step 3
Serve via CDN with adaptive bitrate
The player fetches a manifest and requests segments from the nearest CDN edge, switching quality based on measured bandwidth.
Step 4
Track metadata and engagement asynchronously
View counts, likes, and watch history stream through an event pipeline into eventually consistent counters and the recommendation system.
What Interviewer Expects
- Separates the upload/transcoding pipeline from the read-heavy playback path
- Mentions adaptive bitrate streaming (HLS/DASH) and CDN edge caching
- Recognizes view counts and engagement metrics need eventually consistent, high-write storage rather than strong consistency
- Discusses recommendations/search as decoupled downstream services fed by an event stream
Common Mistakes
- Designing a single database table for both video bytes and structured metadata
- Forgetting transcoding entirely and assuming one video file serves all clients
- Treating view-count increments as strongly consistent row updates at web scale
- Ignoring CDN caching and assuming every playback request hits the origin
Best Answer (HR Friendly)
“I would split the system into three parts: an upload pipeline that converts a raw video into several quality levels, a CDN that caches and serves those videos close to each viewer, and a metadata layer that tracks things like views and comments separately so it can scale on its own. That separation is what lets a platform like YouTube handle both massive uploads and massive concurrent viewing without one part slowing down the other.”
Code Example
job:
videoId: vid_9f21c
sourceUri: s3://raw-uploads/vid_9f21c.mov
renditions:
- resolution: 1080p
bitrateKbps: 5000
codec: h264
- resolution: 720p
bitrateKbps: 2500
codec: h264
- resolution: 360p
bitrateKbps: 800
codec: h264
packaging: hls
onComplete:
publishManifestTo: cdn-origin/vid_9f21c/master.m3u8
emitEvent: video.transcodedFollow-up Questions
- How would you design the view-count system so it scales to millions of concurrent writes?
- How does adaptive bitrate streaming decide when to switch quality mid-playback?
- How would you shard video metadata storage as the catalog grows to billions of videos?
- How would you design the recommendation pipeline without slowing down video playback?
MCQ Practice
1. Why does a video platform transcode uploads into multiple renditions?
Multiple renditions let adaptive bitrate streaming switch quality based on the viewer's real-time network conditions.
2. Why are view counts typically implemented as eventually consistent counters rather than strongly consistent row updates?
At YouTube scale, millions of view events per second make a strongly consistent counter a bottleneck; batched/eventually consistent counters scale far better.
3. What role does a CDN play in a video streaming architecture?
A CDN serves cached segments from edge nodes near the viewer, so the vast majority of playback requests never reach the origin.
Flash Cards
Why transcode a video into multiple renditions? — So the client can adaptively switch resolution/bitrate based on current network conditions.
Why use a CDN for video delivery? — To cache segments close to viewers, cutting latency and origin load for the vast majority of requests.
Why decouple view-count storage from the core metadata DB? — View events arrive at extremely high write volume and only need eventual consistency, not strong consistency.
What streaming protocols handle adaptive bitrate? — HLS and DASH, which package video into segments described by a manifest the client selects from.