System design interview · Hard · about 45 minutes

Design YouTube

Design a video-sharing platform like YouTube. Users upload videos and anyone can watch them smoothly on phones, laptops and TVs, on fast and slow networks.

videotranscodingCDN

Practise it in the interview simulatorDraw your design on a canvas, stress test it with real traffic, and get a scored report. Or watch this answer build itself, step by step.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?: 5 million daily active users who watch 5 videos a day on average.
Which features?: Upload and watch videos. Comments, likes, recommendations and live streaming are out of scope.
What devices and networks?: Mobile, web and smart TVs, from slow 3G to fiber. Playback must adapt to the network.
Video size?: Uploads average 300 MB. The maximum size is 1 GB.
How many uploads?: About 10% of daily users upload one video a day.
Encryption?: Some content needs protection (DRM / encryption); mention it.
Budget?: Cost matters: CDN bandwidth is the biggest bill.

2. Estimate the scale

Assumptions: 5M DAU, 5 videos watched per user per day. 10% upload 1 video a day, 300 MB average. CDN costs $0.02 per GB.

Video uploads per day: about 500K videos5M × 10% = 500K uploads/day.
New storage per day (originals): about 150 TB500K × 300 MB = 150 TB/day.
Video views per second: about 289 views/s5M × 5 ÷ 86,400 ≈ 290 views/s (peak maybe 2-3×).
Daily CDN cost: about 150K $25M views × 300 MB × $0.02/GB ≈ $150,000/day.

3. The high-level design

The reference design. Dashed arrows are asynchronous.

Viewers and creators reach the APIThe API handles everything except video bytes: sign-in, metadata, upload URLs, comments.
Video metadataTitles, owners, processing status and stream URLs live in a replicated database, cached because every page view reads them.
Uploads go straight to storageCreators upload the original file (in chunks, resumable) directly to object storage with a pre-signed URL; the API servers never carry video.
Transcode in the backgroundAn upload event becomes a job on a queue. Transcoders split the work into a DAG of tasks and encode many resolutions and codecs, then mark the video ready.
Stream from a CDNPlayers fetch short segments from a CDN close to them and switch quality as the network changes (adaptive bitrate, HLS/DASH).
Watch it in productionMetrics and alerts close the loop: start-up time, rebuffering, transcoding queue depth and CDN hit ratio.

4. The components and what each one does

Load balancer Load balancer: Spreads requests over the stateless servers behind it, health-checks them and routes around a dead one. Rate limits abusive clients.
API servers App servers: Stateless: any server can handle any request, so you scale out horizontally. Checks the auth token on every request.
Video metadata SQL database: Title, owner, status (uploading/processing/ready), stream URLs. Sharded by video_id; replicas with automatic failover.
Original uploads Object storage · S3: Raw uploads, written directly with a pre-signed URL.
Transcoding queue Message queue: One job per uploaded video.
Transcoders Workers: Split into a DAG (video, audio, thumbnails, watermark); encode many resolutions and codecs in parallel.
Transcoded videos Object storage: Encoded segments and manifests: the CDN's origin.
CDN CDN: Streams segments with adaptive bitrate (HLS/DASH).
Metrics & alerts Metrics & alerts: Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: video processing pipeline

How are uploaded videos transcoded into multiple resolutions and formats? How does playback adapt to the network?

Store the original in object storage, then transcode in the background.
Break transcoding into a DAG of tasks (video, audio, thumbnails, watermark) run by workers.
Stream with adaptive bitrate (HLS/DASH): the player switches quality as bandwidth changes.

6. What interviewers listen for

Upload API (pre-signed URL / resumable)Big uploads go straight to storage via pre-signed URLs, in resumable chunks.
Watch/streaming APIPlayback fetches a manifest listing the available streams.
Video metadata modelTrack each video's owner, status (uploading/processing/ready), title and stream URLs.
Adaptive bitrate streaming (HLS/DASH)The player switches quality as bandwidth changes, which is what makes playback smooth on bad networks.
Transcoding broken into parallel tasks (DAG)Splitting work into tasks (and videos into GOP chunks) lets many workers process one video in parallel.
Cost: serve only popular videos from the CDNCDN cost dominates. Popular videos go to the CDN; the long tail streams from cheaper storage or is encoded on demand.
Resumable, parallel chunked uploadsLarge uploads on mobile fail often; chunks let them resume instead of restarting.
Content protection (DRM, encryption, watermarks)Paid or copyrighted content needs DRM/encryption, and uploads should use signed URLs.
Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

A video goes viral and millions of people try to stream it at the same moment. What happens in your design?
A transcoding worker crashes halfway through a 2-hour video. What happens?
Finance says the CDN bill is too high. How do you cut it without hurting most viewers?
A viewer on a train keeps losing signal. How does your player keep the video going?

Answer them in the simulator

The key points for each follow-up, your scored report and the stress test are part of Pro: ₹299 a month or ₹1,999 a year.

See Pro

The design in a nutshell

Upload: client gets a pre-signed URL and uploads the original (in GOP-aligned chunks) to object storage.
Completion event → queue → preprocessor builds a DAG → resource manager → transcoding workers produce multiple resolutions/codecs.
Encoded videos go to transcoded storage and the CDN; metadata (status, URLs) in a replicated DB + cache.
Playback: the player fetches the manifest and streams segments from the CDN with adaptive bitrate.
Cost: popular content on CDN, long tail from origin; retries per task; DRM/AES for protected content.