Phase 1: Clarify, Scope & Constraints
Interviewer: "Let's design YouTube — a video streaming platform. How would you approach this?"
Candidate: "Great. Before diving in, let me clarify the scope. YouTube does a lot — upload, transcode, stream, recommend, search, comment, monetize. Which dimensions matter most today?"
Interviewer: "Think about it as a greenfield YouTube-scale system. Core journeys: users upload videos, users stream videos. Make it realistic to YouTube's actual scale."
Candidate: "Perfect. Let me identify the three core user journeys I'll design for:
- Upload journey — Creator uploads a video file → it gets processed → it becomes streamable
- Stream journey — Viewer requests a video → gets adaptive-quality playback with low buffering
- Discovery journey — Viewer gets a personalized home feed and search results
The dominant complexity here isn't the happy path — it's the scale mismatch between write (upload/transcode) and read (streaming). Streaming dwarfs uploads by orders of magnitude. YouTube has ~1B DAU who collectively watch 1 billion hours per day, while only ~500 hours of content are uploaded per minute. That's a ~1,400:1 read-to-upload ratio. The design must be heavily read-optimized.
WHY: The second complexity is video transcoding — a single upload triggers generation of 20+ output renditions (8 resolutions × 3 codecs: H.264, VP9, AV1). This makes uploads a compute-intensive async pipeline problem, not a simple object-store write.
Non-goals for V1:
- Live streaming (different architecture — latency constraints, no pre-transcoding)
- Monetization / ads serving
- Comments, likes, subscriptions (user engagement graph)
- Content ID / copyright system
Interviewer: "What about recommendation? That's a huge part…
In the full tutorial
- Phase 2: High-Level Architecture
- Phase 3: Deep Dive & Evolution
- Phase 4: Robustness & Operations