Structure Is Your Safety Net
When an interviewer says "Design YouTube," the worst thing you can do is immediately start drawing boxes. You will make assumptions that turn out to be wrong, design for the wrong scale, and spend 30 minutes on a component the interviewer doesn't care about. The 4-step framework gives you a repeatable structure that keeps the conversation productive and demonstrates seniority.
Step 1: Understand Constraints (5–10 minutes)
Ask questions before drawing anything. The goal is to scope the problem so you're solving the right thing.
- Functional requirements: What does the system do? "Users can upload videos. Users can watch videos. Users can search for videos." Write these down explicitly.
- Non-functional requirements: What are the quality attributes? "Highly available (99.99% uptime). Low latency for reads. Eventual consistency is acceptable for view counts."
- Scale: "How many daily active users (DAU)? How many uploads per day? What's the average video size? How long do we store videos?"
A good opening: "Before I start designing, I'd like to ask a few questions to make sure I'm solving the right problem. Is that okay?" This signals maturity.
Step 2: High-Level Architecture (10–15 minutes)
Draw the "Big Picture" — the major components and how data flows between them. Do not go deep yet. Use standard building blocks:
Client → CDN (static assets)
→ Load Balancer → API Servers → Primary Database
→ Cache (Redis)
→ Object Storage (S3) ← Video Upload
Label every arrow with the protocol or data type: "HTTP/REST", "SQL query", "binary video stream". This shows you understand the interfaces, not just the boxes.
Step 3: Deep Dive (15–20 minutes)
The interviewer will steer you toward one or two components. "How do you handle video processing?" or "Walk me through what happens when a user uploads a video." This is where depth matters.
For each component you dive into, cover:
- Data model: What does the schema or document structure look like?
- Algorithm or mechanism: How does it actually work? (e.g., "We use a consistent hashing ring to distribute shards.")
- Failure modes: What happens when this component goes down?
Step 4: Identify Bottlenecks and Mitigations (5 minutes)
Proactively identify the weakest points in your design before the interviewer does. This is a strong signal of seniority.
- "This single primary database is a Single Point of Failure (SPOF). We mitigate this with a read replica and automated failover."
- "The video processing pipeline is synchronous right now. Under high load, uploads will queue up. We should make it asynchronous with a message queue (Kafka) and a worker pool."
- "Our cache has no eviction policy defined. We should use LRU (Least Recently Used) to keep hot content in memory."