Design YouTube in 45 Minutes Without Embarrassing Yourself

Every candidate starts with the same mistake. They draw a box labeled 'CDN' in the first five minutes and think they're done with video delivery. They're not. They haven't thought about a single hard problem yet.

The First 5 Minutes Are Not For Drawing

Stop. Don't touch the whiteboard.

Ask three questions before you draw anything. How many daily active users? What's the read-to-write ratio? Is this YouTube as it exists today or YouTube circa 2008? These questions tell your interviewer you understand that architecture is a function of constraints, not a function of how many boxes you can draw.

YouTube serves 2.7 billion logged-in users per month. That's your baseline. Reads outnumber writes by something like 10,000 to 1. That asymmetry should drive every single decision you make for the next 40 minutes.

The Part Everyone Gets Wrong: Video Ingestion

In 2021, I was at a 200-person Series B startup trying to build a video platform. We had roughly 800k uploads per day at peak. Our engineers designed the ingestion pipeline to be synchronous. User uploads, we transcode, we return a URL. Simple. Clean. Completely wrong.

Transcoding a 4K video takes 3 to 8 minutes. Making users wait synchronously killed our completion rate by 34%. We dropped to async with a job queue backed by SQS and an SNS notification when processing finished. Completion rate recovered in two weeks. That sync-versus-async mistake cost us roughly $400k in lost subscription revenue before we caught it.

In your interview, draw the async pipeline immediately. Upload service writes raw video to S3. Drops a message on a queue (Kafka, SQS, doesn't matter, pick one and defend it). Transcoding workers pull from the queue, produce multiple renditions (360p, 720p, 1080p, 4K), write each to object storage. Metadata service updates the database. CDN origin gets invalidated. Done. Say this out loud fast and move on.

The Database Question Nobody Answers Well

Your interviewer will ask: what database? Most candidates say Postgres and move on. Don't do this.

There are three separate data problems here. Video metadata (titles, descriptions, upload timestamps) is relational, Postgres is fine. User watch history at YouTube's scale is not. That's Bigtable or Cassandra with a row key of user ID plus timestamp. Comment threads are hierarchical. A naive relational schema for comments at scale turns into a recursive query nightmare. YouTube actually moved comments off of their primary database for this reason.

Pick the right tool for each data shape. Say it explicitly. Interviewers remember candidates who treat the data layer seriously.

The Piece That Decides If You Get The Offer

Here's the thing. Most candidates design a system that works. Very few design a system that degrades gracefully.

Spend your last 8 minutes on failure modes. What happens when the transcoding cluster falls over? (Queue backs up, raw video is safe in S3, users see a 'processing' state, nothing is lost.) What happens when your CDN loses a POP? (Origin pull, latency spikes, not an outage.) What happens when the recommendation service is slow? (Serve cached recommendations, degrade to trending content, never block video playback.)

This is what separates a senior answer from a staff answer. Senior engineers build systems that work. Staff engineers build systems that fail in boring predictable ways.

The goal isn't a perfect design. The goal is a design with no surprises.

I've been on both sides of this interview. The candidates who get offers aren't the ones who know the most facts. They're the ones who make the interviewer feel like they'd be safe shipping code with them.