Learn System Design in 10 DaysDay 1: System Design Interview Basics
Chapter 1Learn System Design in 10 Days

Day 1: System Design Interview Basics

What You'll Learn Today

  • What a system design interview is and why companies use it
  • The five-phase interview flow: requirements, estimation, high-level design, deep dive, wrap-up
  • How to clarify functional and non-functional requirements
  • Back-of-the-envelope estimation (DAU, QPS, storage, bandwidth)
  • Common mistakes and tips for success

What Is a System Design Interview?

A system design interview evaluates your ability to design large-scale distributed systems under ambiguity. Unlike coding interviews that test algorithmic thinking, system design interviews assess how you:

  • Break down vague problems into concrete components
  • Make and justify trade-off decisions
  • Communicate technical ideas clearly
  • Demonstrate awareness of real-world constraints
flowchart LR
    subgraph Interview["System Design Interview"]
        A["Ambiguous Problem"]
        B["Structured Thinking"]
        C["Scalable Design"]
    end
    A --> B --> C
    style A fill:#ef4444,color:#fff
    style B fill:#f59e0b,color:#fff
    style C fill:#22c55e,color:#fff

Most system design interviews last 45 to 60 minutes. The interviewer gives you an open-ended prompt such as "Design Twitter" or "Design a URL shortener," and expects you to drive the conversation.

The Five-Phase Interview Flow

Every system design interview should follow a structured approach. Jumping straight into a whiteboard diagram is one of the most common mistakes candidates make.

flowchart TB
    subgraph Flow["Interview Flow (45-60 min)"]
        R["1. Requirements<br>5 min"]
        E["2. Estimation<br>5 min"]
        H["3. High-Level Design<br>15-20 min"]
        D["4. Deep Dive<br>15-20 min"]
        W["5. Wrap-Up<br>5 min"]
    end
    R --> E --> H --> D --> W
    style R fill:#3b82f6,color:#fff
    style E fill:#8b5cf6,color:#fff
    style H fill:#22c55e,color:#fff
    style D fill:#f59e0b,color:#fff
    style W fill:#ef4444,color:#fff
Phase Duration Goal
Requirements ~5 min Clarify scope, users, and constraints
Estimation ~5 min Quantify scale (QPS, storage, bandwidth)
High-Level Design ~15-20 min Draw the architecture with key components
Deep Dive ~15-20 min Drill into 1-2 critical components
Wrap-Up ~5 min Discuss trade-offs, bottlenecks, future improvements

Phase 1: Requirements (5 minutes)

Never start designing before you understand what to build. Ask questions to narrow the scope.

Functional requirements define what the system does:

  • What are the core features?
  • Who are the users?
  • What are the input and output?

Non-functional requirements define how the system behaves:

  • How many users? (scale)
  • What latency is acceptable? (performance)
  • Can we tolerate data loss? (durability)
  • What uptime is required? (availability)

Tip: Write down your requirements on the whiteboard. This shows the interviewer you are organized and gives you a reference throughout the interview.

Phase 2: Estimation (5 minutes)

Back-of-the-envelope calculations help you determine the scale of the system and guide your design decisions.

Phase 3: High-Level Design (15-20 minutes)

Draw the major components and how they interact. Start with the simplest design that satisfies the requirements, then iterate.

Phase 4: Deep Dive (15-20 minutes)

The interviewer will ask you to go deeper into one or two components. This is where you demonstrate expertise in specific areas like database design, caching, or consistency models.

Phase 5: Wrap-Up (5 minutes)

Summarize your design, acknowledge trade-offs, and suggest improvements you would make with more time.

Clarifying Requirements

The ability to ask good questions separates strong candidates from average ones. Here is a framework for requirement gathering.

flowchart TB
    subgraph Functional["Functional Requirements"]
        F1["Core features"]
        F2["User actions"]
        F3["Data flow"]
    end
    subgraph NonFunctional["Non-Functional Requirements"]
        N1["Scale / DAU"]
        N2["Latency / Performance"]
        N3["Availability / Durability"]
    end
    subgraph Constraints["Constraints"]
        C1["Budget"]
        C2["Tech stack"]
        C3["Timeline"]
    end
    style Functional fill:#3b82f6,color:#fff
    style NonFunctional fill:#8b5cf6,color:#fff
    style Constraints fill:#f59e0b,color:#fff

Example: "Design a URL Shortener"

Category Question Example Answer
Functional Can users create custom short URLs? Yes, optional
Functional Do short URLs expire? Yes, after 5 years by default
Non-Functional How many URLs are shortened per day? 100 million
Non-Functional What is the read-to-write ratio? 10:1
Non-Functional What latency is acceptable for redirection? < 100ms
Constraint Do we need analytics (click tracking)? Yes, basic analytics

Back-of-the-Envelope Estimation

Estimation is a critical skill. You need to quickly calculate numbers that influence architectural decisions.

Key Numbers to Memorize

Metric Value
Seconds in a day ~86,400 (~100,000 for easy math)
Seconds in a month ~2.5 million
1 million requests/day ~12 QPS
1 billion requests/day ~12,000 QPS
1 KB text ~1,000 characters
1 MB image ~1,000 KB
1 GB ~1,000 MB
1 TB ~1,000 GB

QPS (Queries Per Second)

QPS = DAU x (average queries per user per day) / 86,400
Peak QPS = QPS x 2 (or x3 for spiky traffic)

Storage Estimation

Daily storage = DAU x (actions per user per day) x (data size per action)
Monthly storage = Daily storage x 30
Yearly storage = Daily storage x 365

Bandwidth Estimation

Incoming bandwidth = QPS x (average request size)
Outgoing bandwidth = QPS x (average response size)

Worked Example: Social Media Platform

Assume:

  • DAU: 100 million
  • Each user posts 0.5 times per day (50 million posts/day)
  • Each user reads 20 posts per day (2 billion reads/day)
  • Average post size: 1 KB text + 200 KB media = ~200 KB

Write QPS:

50,000,000 / 86,400 ≈ 600 QPS
Peak: 600 x 3 = 1,800 QPS

Read QPS:

2,000,000,000 / 86,400 ≈ 23,000 QPS
Peak: 23,000 x 3 = 69,000 QPS

Daily Storage:

50,000,000 posts x 200 KB = 10 TB/day

Bandwidth (outgoing):

23,000 QPS x 200 KB = 4.6 GB/s

These numbers tell us we need heavy read optimization (caching, CDN) and significant storage capacity.

Common Mistakes and Tips

Mistakes to Avoid

flowchart TB
    subgraph Mistakes["Common Mistakes"]
        M1["Jumping into design<br>without requirements"]
        M2["Over-engineering<br>from the start"]
        M3["Ignoring<br>non-functional requirements"]
        M4["Monologuing without<br>checking in"]
        M5["Not discussing<br>trade-offs"]
    end
    style Mistakes fill:#ef4444,color:#fff
    style M1 fill:#ef4444,color:#fff
    style M2 fill:#ef4444,color:#fff
    style M3 fill:#ef4444,color:#fff
    style M4 fill:#ef4444,color:#fff
    style M5 fill:#ef4444,color:#fff
Mistake Why It Hurts What to Do Instead
Skipping requirements You solve the wrong problem Spend 5 minutes asking questions
Over-engineering Shows poor judgment Start simple, add complexity as needed
Ignoring scale Design may not work at scale Always estimate QPS and storage
Not communicating Interviewer cannot evaluate your thinking Narrate your thought process
Single solution Shows inflexibility Present alternatives with trade-offs

Tips for Success

  1. Drive the conversation - The interviewer expects you to lead
  2. Think out loud - Verbalize your reasoning, even when uncertain
  3. Start simple - Begin with a basic design and evolve it
  4. Quantify everything - Use numbers to justify decisions
  5. Discuss trade-offs - Every design choice has pros and cons
  6. Use the whiteboard effectively - Draw clear, labeled diagrams
  7. Manage your time - Do not spend 30 minutes on requirements

Practice Problems

Exercise 1: Basics

Estimate the QPS and daily storage for a URL shortener with the following assumptions:

  • 10 million DAU
  • Each user creates 0.1 short URLs per day
  • Each user clicks 5 short URLs per day
  • Each URL record is 500 bytes

Exercise 2: Applied

You are asked to "Design Instagram." Write down:

  1. Five functional requirements
  2. Five non-functional requirements
  3. Back-of-the-envelope estimation for QPS, storage, and bandwidth (assume 500 million DAU)

Challenge

Practice a full 45-minute mock interview for "Design a Chat Application." Follow all five phases and write down your requirements, estimations, high-level design (as a diagram), one deep-dive topic, and a wrap-up summary with trade-offs.

Summary

Concept Description
System Design Interview Evaluates ability to design scalable distributed systems
Five Phases Requirements, Estimation, High-Level Design, Deep Dive, Wrap-Up
Functional Requirements What the system does (features, user actions)
Non-Functional Requirements How the system behaves (scale, latency, availability)
QPS Estimation DAU x queries per user / 86,400
Storage Estimation Daily actions x data size per action
Bandwidth Estimation QPS x average response size

Key Takeaways

  1. Always start with requirements - never jump into design
  2. Estimation drives architecture - the numbers determine which components you need
  3. Communication is as important as the design - think out loud and check in with the interviewer
  4. Trade-offs are the heart of system design - there is no perfect solution, only trade-offs

References

Next up: On Day 2, we explore Scalability and Performance - the foundational concepts of horizontal scaling, load balancing, the CAP theorem, and how to reason about availability and latency in distributed systems.