Design YouTube in 45 Minutes Without Dying

Stop starting with the database.

I'm serious. Every candidate I've interviewed in the last three years opens with "so I'll use PostgreSQL with a users table..." and I've already mentally moved on. You've failed. Not because PostgreSQL is wrong. Because you skipped the part that actually matters.

The First 5 Minutes Are Everything

Here's the thing: YouTube is not a video problem. It's a read-heavy, globally distributed, latency-sensitive metadata problem that happens to have video attached to it. The candidate who says that in the first two minutes looks like someone who's shipped at scale. The candidate who draws a box labeled "video server" looks like someone who read a blog post the night before.

Start by narrowing scope aggressively. Ask: are we designing upload, playback, or both? Are we targeting 1M DAU or 1B? Do we care about live streaming? Force the interviewer to make choices. This signals systems thinking. It also buys you 3 minutes to think.

The War Story That Shaped How I Think About This

In 2019, my team at Netflix was handling roughly 200M streaming sessions per day. We had a caching layer that looked perfect on the whiteboard. Redis clusters, CDN in front, the works. What we didn't model was cache stampedes during new episode drops. Stranger Things season 3 dropped and within four minutes we had 40,000 concurrent cache misses hitting origin simultaneously. Not because the cache was too small. Because our TTLs were synchronized. Every key expired at the same second. That outage cost us roughly $600k in emergency infrastructure scaling and two engineers' weekends. The fix was adding 0-30 seconds of jitter to TTL on write. One line of code. Three days of cleanup.

When you're designing YouTube in an interview, mention cache stampedes. Mention jitter. Watch the interviewer's face. That's the moment they know you've actually operated something.

The Framework I Actually Use

Write these five words at the top of the whiteboard: Ingest. Store. Process. Serve. Observe.

That's the whole system. Work through each one in order. Don't skip to serving because it feels more interesting. Ingest is where the hard problems live.

For ingest: chunked upload over HTTP, resumable via the TUS protocol or YouTube's own resumable upload API pattern. Client splits video into 5MB chunks, uploads with a session ID, server reassembles. This handles mobile networks dropping mid-upload. Don't invent a custom protocol. I've seen teams do this. It ends badly every time.

For processing: you're not building a transcoding pipeline in 45 minutes. Say "I'd use a job queue — SQS or Kafka — feeding a fleet of FFmpeg workers running on spot instances, outputting to S3 in HLS format at 360p, 720p, and 1080p." That sentence takes 15 seconds to say and it's correct.

For serving: CDN-first, always. Cloudfront or Fastly. Manifest files served from your own origin so you control routing. Actual video bytes served from CDN edge nodes. Adaptive bitrate via HLS. Don't design an origin that can survive a Stranger Things drop. Design one that never sees it.

What Most People Get Wrong About Scale Numbers

YouTube processes 500 hours of video per minute. That's not a fun fact. That's a constraint. If you're designing the upload pipeline and you haven't talked about back-pressure, you haven't designed anything. What happens when transcoding workers fall behind? Does the queue grow forever? Does the upload API start returning 503s? Pick one. Defend it. The answer matters less than having one.

The Last 5 Minutes

This is where you win or lose. Most candidates trail off. Don't. Hit observability hard. Say you'd track upload success rate, time-to-first-byte on playback, transcoding queue depth, and CDN cache hit ratio. Name Datadog for metrics, Grafana for dashboards. Say what your SLO is: 99.9% playback availability measured over 28 days. Then say what breaks that SLO first. Probably the metadata service, not the CDN.

Interviewers remember the candidate who knew where the system would fail. Be that person.