# The first thing you should do in a System Design Interview

The interviewer says "Design Twitter" and slides a marker across the table. Your hand twitches toward the whiteboard, ready to draw a load balancer and three boxes labelled "service." Stop. The first thing to do in a system design interview is **not to design anything.** It is to spend the next 5 to 10 minutes turning that vague, deliberately under-specified prompt into a scoped problem you and the interviewer both agree on.

This is the opening post in the System Design Guide series, so we start where the interview actually starts: the sixty seconds after the problem statement lands, and what a strong candidate does with them.

## Why jumping straight to a design is the trap

The prompt is vague on purpose. "Design Twitter," "design a rate limiter," "design a web crawler" - none of these has a right answer, and the interviewer knows it. Nobody expects you to rebuild in 45 minutes what took thousands of engineers years. The interview is a simulation of two coworkers resolving an ambiguous problem together, and the design you end up with matters less than how you get there.

So when you start throwing components on the board in the first minute, you are sending exactly the wrong signals:

- You look like you are answering from memory, not thinking.
- You commit to a system before you know what it is supposed to do, which usually means you design the *wrong* system and have to walk it back later.
- You skip the one skill every interviewer is explicitly watching for: **the ability to ask good questions and resolve ambiguity.**

There is also a red flag lurking here called over-engineering. A design that solves a young startup's problem looks nothing like one built for 500 million users. If you do not know which one you are being asked for, you cannot make a single sensible decision. The only way to know is to ask.

## The first move: turn the prompt into scope

The actual first thing to do is drive a short round of clarifying questions. You are trying to answer one question for yourself before you draw anything: *what exactly am I building, and at what scale?*

A clean way to organize this is to split every clarifying question into two buckets:

1. **Functional requirements** - what the system does. The features. The verbs.
2. **Non-functional requirements** - how well it has to do them. Scale, latency, availability, consistency.

Freshers almost always remember the first bucket and forget the second. The second bucket is where senior signal lives, because it is what actually forces architectural decisions.

### Bucket one: what does it do?

Nail down the feature set before anything else. For "Design Twitter" you do not build all of Twitter - you agree on the two or three core features that matter for this session.

| Ask | Why it changes the design |
|---|---|
| What are the core features we must support? | Scopes the whole problem. "Post a tweet + view a timeline" is a different system than "+ DMs + search + ads." |
| Web, mobile, or both? | Affects API shape and whether you need a mobile-friendly push model. |
| Who are the actors? | A read-only consumer, a poster, and an admin have different flows. |
| Is X in scope? (search, notifications, media) | Explicitly cut things so you are not judged for skipping them. |

Write the agreed feature list somewhere visible and treat it as the contract for the rest of the hour. If a feature is not on it, it is out of scope, and you get to say so later instead of getting caught.

### Bucket two: how well, and at what scale?

This is the bucket that separates a scoped design from a toy. The exact questions vary by problem, but the axes are almost always the same:

- **Scale / traffic:** How many daily active users? How many reads and writes per second? This gives you QPS to design against.
- **Read vs write ratio:** Is it read-heavy (a timeline, a news feed) or write-heavy (a logging pipeline)? A heavily read-skewed system is the classic case for separating your read and write paths, which is exactly what a pattern like [CQRS](/command-query-responsibility-segregation-cqrs) exists to do.
- **Latency:** Does a request need to feel instant (sub-100ms) or is a few seconds fine?
- **Availability vs consistency:** Can the system briefly show slightly stale data (eventual consistency) to stay up, or must every read be perfectly correct? You cannot have both at the extreme, and picking one is a real design decision.
- **Data characteristics:** How big is a record? Do we store media? For how long? A feed that stores images and videos pulls in object storage and things like [presigned URLs](/what-are-presigned-urls); a text-only feed does not.
- **Growth:** What scale in 3 months, 6 months, a year? This tells you whether to design for today or for 10x.

You will not ask all of these. Pick the three or four that actually move the design for *this* problem and ask those.

## Put rough numbers on it

Once the features and scale are agreed, do a quick back-of-the-envelope estimation. You are not looking for precision - you are looking for the order of magnitude that tells you whether a single database is fine or whether you need sharding, caching, and a CDN.

Say the interviewer gives you 300 million monthly active users, half of them active daily, posting 2 items a day, 10% with media. The math you do out loud looks like this:

```text
DAU        = 300M * 50%              = 150M
Write QPS  = 150M * 2 / 86400        = ~3,500 writes/sec
Peak QPS   = 2 * 3,500               = ~7,000 writes/sec

Media/day  = 150M * 2 * 10% * 1MB    = ~30 TB/day
5-yr media = 30 TB * 365 * 5         = ~55 PB
```

Two things make this go well:

- **Round aggressively.** Nobody wants to watch you compute `99987 / 9.1` in your head. Turn it into `100000 / 10`. Precision is not the point; the exponent is.
- **Label your units.** Writing "5" is useless. "5 MB" and "5 ms" are the numbers that let you reason. Confusing KB with MB is how a design quietly becomes wrong.

If you want an intuition for what these numbers *mean* in practice - why memory is fast and disk seeks are slow, why sending data across regions costs real time - keep the [latency numbers every programmer should know](https://colin-scott.github.io/personal_website/research/interactive_latency.html) in your head. They are the reason a cache shows up in almost every design.

## Write down assumptions, then read the scope back

Sometimes you ask a question and the interviewer says "you tell me." That is not a dead end - it is an invitation. Make a reasonable assumption, **say it out loud, and write it on the board.** "I'll assume a user can follow up to 5,000 accounts and the timeline is reverse-chronological, is that fair?" You have now converted ambiguity into a written decision you can point back to.

Close this phase by reading the scope back in one or two sentences: *"So we're building a web and mobile service where a user can post and view a reverse-chronological timeline, roughly 150 million DAU, read-heavy, media allowed, eventual consistency is fine. Sound right?"* Get the nod. That nod is your green light to actually start designing, and it means everything you draw next is anchored to something you both agreed on.

## What this looks like in real time

Here is the whole first phase compressed into the kind of exchange you are aiming for:

```text
You:  What are the core features - are we doing posting and a timeline,
      or also search, DMs, notifications?
Int:  Just posting and viewing a timeline.
You:  Reverse-chronological, or ranked?
Int:  Keep it reverse-chronological.
You:  Web, mobile, or both?
Int:  Both.
You:  Rough scale? DAU and how many posts per user per day?
Int:  150 million DAU, 2 posts a day, assume 5,000 follows max.
You:  Can posts include media, and how long do we retain it?
Int:  Images and video, retained indefinitely.
You:  It's clearly read-heavy, and I'll assume eventual consistency on the
      timeline is acceptable - a post can take a second to fan out. OK?
Int:  That's fine.
```

That is maybe eight minutes. You have not drawn a single box, and you are already in a far stronger position than the candidate who started with "so, load balancer..." at minute one.

## How long the first thing should take

Time is the scarcest resource in the room. A rough split for a 45-minute session:

| Step | Time |
|---|---|
| 1. Understand the problem and establish scope | 3 - 10 min |
| 2. Propose a high-level design and get buy-in | 10 - 15 min |
| 3. Deep dive on the critical components | 10 - 25 min |
| 4. Wrap up (bottlenecks, failures, next scale) | 3 - 5 min |

Scoping is short but load-bearing. Spend under three minutes and you will design blind; spend twenty and you will run out of clock before you have designed anything. Aim for five to ten, get the nod, and move on.

## Mistakes that quietly cost people the loop

- **Designing before scoping.** The single most common failure. Drawing boxes at minute one reads as memorized, not thought-through.
- **Only asking about features.** Skipping scale, latency, and consistency is how you build a toy and get graded as a fresher.
- **Asking questions and ignoring the answers.** If you asked about scale, your design had better reflect that scale. Otherwise the questions look performative.
- **Silent thinking.** The interviewer cannot grade what they cannot hear. Narrate the trade-offs; treat them as a teammate, not an examiner.
- **Treating your assumptions as facts.** Every assumption is a question you answered for yourself. Say it out loud so it can be corrected before it poisons the design.

## You now have the opening move

The first thing to do when a system design problem lands is to refuse to design it yet: split your clarifying questions into functional and non-functional buckets, put rough labelled numbers on the scale, write your assumptions on the board, and read the scope back until you get a nod. Do that in under ten minutes and everything you build afterward stands on solid ground instead of a guess.

That nod is the handoff to step two. In the next post in this series we take the scoped, numbered problem from here and turn it into a high-level design - the boxes, the data flow, and how to get the interviewer to buy in before you go deep. The framework in this series follows the one laid out in Alex Xu's [System Design Interview](https://bytebytego.com); if you want a broader question bank to practice scoping against, the open-source [system design primer](https://github.com/donnemartin/system-design-primer) is worth bookmarking.