What are the six steps of a system design interview, in order?

Clarify requirements (functional and non-functional), estimate the scale, define the API and data model, sketch the high-level design, deep-dive into the hardest parts, then wrap up with trade-offs and next steps.

Why start with a simple design rather than a fully scaled one?

A simple working design proves you understand the core flow, and scaling decisions are only convincing when they fix a bottleneck you can point to with numbers. Starting with every distributed component looks like memorised buzzwords and leaves no time for real trade-offs.

How to Run a System Design Interview — System Design Interviews, Step by Step

The problem

"Design a URL shortener." Forty-five minutes, a blank whiteboard, and an interviewer who says almost nothing. Most candidates who struggle don't lack knowledge; they jump straight into drawing databases, run out of time, and never discuss trade-offs. Others ask questions for twenty minutes and never design anything.

Real-world analogy

An architect asked to design a house doesn't start by choosing bricks. They ask how many people will live there, the budget and the plot size, sketch the floor plan, and only then detail the kitchen and the stairs. A system design interview rewards the same order.

The idea

Use the same six steps every time, with a rough time budget for a 45-minute round:

Step	Time	What you do
1. Clarify the requirements	5 min	Functional (what it does) and non-functional (scale, latency, availability, consistency). Agree what's out of scope.
2. Estimate the scale	3–5 min	Users, requests per second, storage, bandwidth. Only what changes the design.
3. API and data model	5 min	The main endpoints and the core tables or records.
4. High-level design	10 min	Boxes and arrows for the main flows: clients, load balancer, services, database, cache, queue.
5. Deep dives	15 min	Two or three hard parts in depth: the bottleneck, the tricky consistency problem, the scaling plan. Often the interviewer picks.
6. Wrap up	2–3 min	Trade-offs you made, what breaks first, what you'd do next.

Habits that score well:

Think out loud and check in: "I'll assume 100 million users; does that sound right?"
Start simple, then scale. A single server and database that works, then fix its bottlenecks one by one.
Name trade-offs. "A cache makes reads fast but can serve stale data for up to 60 seconds; for a profile page that's fine."
Let the numbers drive decisions. "12,000 writes per second is too much for one database, so we shard."
Draw the data flow for the main use case end to end before optimising anything.

The code

A study aid: given a list of what you covered, this script checks your answer against the six steps and the time budget, the way an interviewer's rubric would.

Self-check your mock interview against the frameworkTry it yourself

STEPS = [
    ("requirements", 5, "Clarify functional and non-functional requirements"),
    ("estimates", 4, "Estimate traffic, storage and bandwidth"),
    ("api", 5, "Define the API and data model"),
    ("high-level", 10, "Sketch the high-level design"),
    ("deep-dive", 15, "Go deep on the hardest parts"),
    ("wrap-up", 3, "Summarise trade-offs and next steps"),
]

# What you actually did in a practice run: (step, minutes spent)
my_run = [("requirements", 2), ("high-level", 25), ("deep-dive", 15)]

spent = dict(my_run)
total = sum(spent.values())
print(f"Total time: {total} min (target 42)\n")
for step, budget, description in STEPS:
    used = spent.get(step)
    if used is None:
        verdict = "MISSED"
    elif used > budget * 1.5:
        verdict = f"over budget ({used} min vs ~{budget})"
    elif used < budget * 0.5:
        verdict = f"rushed ({used} min vs ~{budget})"
    else:
        verdict = f"ok ({used} min)"
    print(f"{description:<52} {verdict}")

Output

Total time: 42 min (target 42)

Clarify functional and non-functional requirements   rushed (2 min vs ~5)
Estimate traffic, storage and bandwidth              MISSED
Define the API and data model                        MISSED
Sketch the high-level design                         over budget (25 min vs ~10)
Go deep on the hardest parts                         ok (15 min)
Summarise trade-offs and next steps                  MISSED

This run is the classic failure: almost no requirements, a 25-minute diagram, and no estimates, API or wrap-up. Run your own practice sessions through it.

Common mistakes

Designing before clarifying. A chat app for 50 people and one for 500 million users are different systems.
Over-engineering from the start. Kafka, microservices and sharding for a system that a single database could run. Start simple and scale where the numbers say so.
Silent drawing. The interviewer can't give credit for reasoning they can't hear.
No trade-offs. Every choice (SQL vs NoSQL, push vs pull, strong vs eventual consistency) has a cost. Say what it is.
Fighting the interviewer's steer. "Let's talk about how you'd scale the database" means move there now.

Key points

Six steps: requirements, estimates, API and data, high-level, deep dives, wrap-up.
Budget your time; most of it goes to the high-level design and the deep dives.
Start simple, let the numbers justify every scaling step.
Talk through trade-offs; that's what separates senior answers.