System Design Interview Methodology

Question 1

In the system design interview framework, what is the FIRST thing you should do after being given a prompt like "design Twitter"?

Accepted Answer

Ask clarifying questions about functional requirements, scale, and scope before proposing any architecture — The framework's first step is always clarifying requirements — functional scope, non-functional constraints, and scale. Jumping to any design without these answers means you may design the wrong system entirely.

Question 2

Why does the framework place back-of-envelope capacity estimation BEFORE the high-level design step?

Accepted Answer

The numbers derived from estimation — queries per second, storage growth, bandwidth — determine which architectural choices are justified; the design follows from the constraints estimation reveals — Estimation produces the constraints that justify every subsequent design decision — whether you need a cache, a CDN, database sharding, or horizontal scaling. A high-level design without these numbers is pattern-matching to buzzwords, not engineering.

Question 3

An interviewer gives you "design a notification system" with no other details. Which clarifying question is MOST critical to ask first?

Accepted Answer

Should the notification system support push, email, and text messages, or just one channel? — Understanding the functional scope — what types of notifications the system must support — defines the entire problem shape. Cloud provider, language, and architectural style are secondary until you know what the system actually needs to do.

Question 4

You finish presenting your high-level diagram and the interviewer says "let's zoom in on the message queue." What does this signal, and what should you do?

Accepted Answer

They have seen enough breadth and want to assess depth — go deep on that component: name the data model, failure modes, and at least one alternative you considered — An interviewer steering toward a specific component signals they want to test depth, not that your high-level design was wrong. The correct response is to go genuinely deep — discuss the data model, failure modes, and at least one alternative you considered.

Question 5

What should the "tradeoffs and bottlenecks" step of the framework explicitly include?

Accepted Answer

An explicit statement of what the design gives up, what breaks first at 10× scale, and a concrete mitigation — not a claim that the design is solid — The tradeoffs step should proactively name the design's weakest points — the first component to fail under load, the consistency vs availability tradeoff made, the latency vs throughput decision — and a concrete mitigation. Claiming a design has no bottlenecks is a red flag to interviewers.

Question 6

The "define the API" step appears after requirements and estimation but before the high-level diagram. Why does the framework order it there?

Accepted Answer

Defining the API surface makes scope concrete — method names, parameters, and return types resolve ambiguity before boxes and arrows could represent the wrong system — The API step acts as a precise contract between the clarified requirements and the high-level design. It forces you to make scope concrete before drawing boxes and arrows — preventing the common failure mode of designing a system that doesn't match what the product actually needs.

Question 7

An interviewer asks you to design a ride-sharing app. They ask: 'What latency should the driver-matching response have, and what is the maximum acceptable system downtime per month?' What category of requirements are these, and how do they differ from the first set of requirements you should clarify?

Accepted Answer

Both are non-functional (quality-of-service) requirements — they define how well the system performs, not what it does; functional requirements such as ride-matching are clarified first to bound the problem scope — System design interviews have two distinct requirement classes. Functional requirements define WHAT the system does: 'riders can request a ride,' 'drivers can accept or reject requests,' 'users can see trip history.' Non-functional requirements define HOW WELL it performs: latency targets (p99 < 500ms), availability SLA (99.99% = ~52 min downtime/year), durability (no payment data loss), throughput (peak 100K requests/sec). Always clarify functional requirements first to bound the problem, then establish non-functional requirements to guide architecture choices like caching, replication, and consistency models.

Question 8

A social media app has 100 million daily active users. Each user makes an average of 10 actions per day. Estimate the average requests per second (QPS).

Accepted Answer

Approximately 10,000 QPS — calculated as 100M × 10 ÷ 86,400 seconds per day ≈ 11,574 QPS, rounded to ~10K — The standard back-of-envelope shortcut: 1 day ≈ 86,400 seconds ≈ 100,000 seconds (a useful approximation). 100M DAU × 10 actions = 1 billion daily requests. 1B ÷ 100,000 = 10,000 QPS average. For interviews, remember the approximation: DAU × actions ÷ 10^5. Peak QPS is typically 2–5× average. This estimate immediately tells you whether you need sharding, load balancers, caching layers — or whether a single well-tuned server suffices.

Question 9

Your analytics dashboard shows that 99 out of 100 requests are reads and 1 is a write. How should this heavily skewed read/write ratio shape your architecture?

Accepted Answer

Invest in read-path optimizations: add a cache layer (Redis/Memcached), read replicas, and denormalization — 99% of load is on the read side, so that is where scaling effort pays off — A 99:1 read-to-write ratio means virtually every user-facing request is a read. The architectural implications: (1) Caching is high-value — a cache hit rate of 90% reduces database read load by 10×. (2) Read replicas let multiple database instances serve read traffic in parallel, scaling linearly. (3) Denormalization (flattening joined tables into single documents) eliminates expensive multi-table joins on the read path. The write path, handling 1% of traffic, rarely needs scaling optimizations — the focus is almost entirely on making reads faster and cheaper.

Question 10

You are designing a banking ledger. A network partition occurs between two data centers. You choose to reject all writes during the partition rather than allowing both sides to accept writes. Which part of the CAP theorem does this reflect, and what is the tradeoff?

Accepted Answer

This is a CP system — it sacrifices availability during a partition so that any data served is guaranteed consistent; users may get errors but never see conflicting reads — CAP theorem states that during a network partition, a distributed system must choose between Consistency and Availability — it cannot guarantee both. A banking ledger chooses Consistency (CP): rather than allowing both data centers to accept conflicting writes (which would mean account balances could be spent twice), the system rejects writes on the side that cannot confirm consistency with the other partition. Users see errors or timeouts during the outage, but when service resumes, the data is guaranteed correct. AP systems (like DNS or shopping carts) choose to remain available but may return stale data — acceptable for product catalogs, unacceptable for financial records.

Clarify Requirements

Applying “Clarify Requirements” in practice

Run the interview

Test your knowledge

In the system design interview framework, what is the FIRST thing you should do after being given a prompt like "design Twitter"?

The short version

Interview Questions

References & Further Reading

Love this visualization?