YouTube Video Platform – System Design Interview Preparation

Practice designing a video sharing platform like YouTube. Cover video upload, transcoding, streaming, and recommendations.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the YouTube design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing YouTube is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

An asynchronous transcoding pipeline and adaptive streaming. Upload and playback are two different systems that happen to share a video id.

Scale to establish before drawing anything

500 hours uploaded a minute; each source is transcoded into 5-8 renditions, so processing is many times real time.
A 10-minute 1080p video is roughly 500 MB as source and more across all renditions - storage is the dominant cost.
Playback is overwhelmingly CDN-served; origin traffic should be a rounding error.

Core components

Upload service – Chunked, resumable upload to object storage. Returns immediately.
Transcoding pipeline – A DAG of jobs - split, encode per rendition, package into segments, generate the manifest. Parallelised by chunk.
Segment storage – Short segments plus a manifest, which is what makes adaptive bitrate possible.
CDN – Serves segments. Popular videos are pushed; the long tail is pulled on first request.
Metadata and recommendation services – Separate from the media path entirely.

Trade-offs to defend

Adaptive bitrate – The client picks a rendition per segment based on measured bandwidth. This is why video is stored as segments rather than files, and it is the detail that separates a real answer from a sketch.
Transcode everything up front versus on demand – Most videos are watched almost never. Transcoding the long tail lazily saves enormous compute at the cost of first-view latency.
Push versus pull CDN – Push for predicted-popular content, pull for the tail. Getting the prediction wrong is expensive in both directions.

Follow-up questions to expect

A transcoding job fails at rendition 6 of 8. Does the video go live, and what does the user see?
A video goes viral in a region with no cached copy. Describe the first 10,000 requests.
Add live streaming. Which parts of this design survive, and which do not?