How to Approach a System Design Interview

You get one sentence. "Design Instagram." Or "Design a chat app." Then the interviewer leans back and waits.

Most people freeze for a few seconds and then do the same thing: they start drawing a database. It feels like progress. It is usually the start of a bad interview.

The problem is not that you lack knowledge. The problem is that nobody told you what to do first. So this note gives you a flow you can repeat on any question. Same order every time. Once the order is automatic, your brain is free to think about the actual problem.

What is really being checked

It helps to know the real exam. Nobody expects you to rebuild Instagram in 45 minutes. They want to see how you think when the problem is vague and big.

They are watching for a few things:

• Do you ask before you build?
• Do you pick a sensible size for the problem, or do you design for a billion users by reflex?
• Can you explain a choice with a reason, and say what it costs you?
• When they poke at your design, do you stay calm and adjust?

There is no single correct answer. Two good candidates can draw very different boxes and both do well. What fails is a design with no reasons behind it.

The flow in one picture

Six steps. Think of it like building a house. You talk to the owner first, then you measure the plot, then you draw the plan, and only then do you worry about which wiring to use in the kitchen. Nobody starts with the wiring.

Step 1: Ask questions

The question you were given is deliberately vague. "Design a chat app" could mean a two person messenger or something with video calls, channels, bots and file sharing. If you guess, you might design the wrong thing for 40 minutes.

So you ask. This also shows the interviewer that you would ask in a real job too, which is what they want to see.

Here are the kinds of questions that work. You do not need all of them. Pick the ones that change the design.

Questions about what the product does:

• "Who uses this, and what is the one main thing they do?"
• "Which features are in scope, and which can I leave out?" (For a chat app: one to one only, or groups too? Do we need read receipts? Media?)
• "Is this a new product or are we replacing an old one?"

Questions about size:

• "How many users do we expect? How many are active in a day?"
• "Roughly how many requests or messages per user per day?"
• "Do we need to support just one country or the whole world?"

Questions about how it should behave:

• "Is it fine if a user sees slightly old data for a few seconds, or must everyone always see the latest?"
• "How fast should the main action feel? Under a second? Instant?"
• "Can we ever lose data, or is losing one item a disaster?"
• "What happens if the service is down for a minute? Annoying, or very expensive?"

Questions about limits:

• "Any size limits? For example, the longest message, or the biggest file."
• "Any rules about how long we keep data?"
• "Are there existing systems or tools I must use, or do I have a free hand?"

Notice the pattern. Each question is really asking for a number or a choice that will change a box on your drawing. "Can data be a little old?" decides whether you can use a cache and copies of the database freely. "Can we lose a message?" decides how careful the write path must be. If a question would not change your design, skip it.

Some interviewers answer everything. Some say "you decide". If they say that, do not panic. Pick a reasonable answer, say it out loud ("I will assume 10 million daily users, tell me if that is off") and move on. Saying your assumption out loud is the skill. It is not a failure to assume.

Step 2: Write the requirements down

Now put the answers on the board, in two short lists. People like to skip this step. Do not.

Functional requirements are the things the system does. Write them as short actions.

Chat app, functional:
- send a message to one person
- see the message history of a chat
- see if the other person is online
Out of scope: groups, video calls, file sharing

Non functional requirements are how well it does them: fast, always up, never loses data, handles lots of users. Pick the three or four that matter most for this product.

Chat app, non functional:
- messages arrive in under 1 second
- no message is ever lost
- stays up even if one machine dies
- ok if "online" status is a few seconds late

Two reasons this step pays off. First, the interviewer can correct you now, which is far cheaper than correcting you at minute 35. Second, you now have a checklist. At the end you can walk back through it and say "here is how the design meets each line".

The "out of scope" line matters more than it looks. It is you telling the interviewer "I know this exists, I am choosing not to design it". That sounds senior.

Step 3: Estimate the numbers

Before you draw boxes, get a rough idea of the size. Is this 100 requests a second or 100,000? Is the data 10 GB or 10 TB? A system for 100 requests a second can be one server and one database. A system for 100,000 needs a very different plan.

You do not need exact numbers. You need the right number of zeros. There is a whole separate note on this called Back of the Envelope Estimation, so here is only the short version:

1. Start from daily users.
2. Work out requests per day, then requests per second (divide by about 100,000, since a day has roughly that many seconds once you round).
3. Work out how much data one request creates, then storage per year.
4. Say what the number tells you.

The last step is the one people forget. A number that does not change a decision is just trivia. "That is about 5,000 reads a second, so one database will struggle and I want a cache in front" is the sentence that scores points.

Step 4: Draw the boxes

Now you draw. Start simple and boring: a client, something that receives requests, something that stores data. Then add pieces only when a requirement or a number asks for them.

That is a fine first drawing for almost anything. A load balancer is just the person at the door who sends each visitor to a free counter. App servers hold your code. The database holds the data.

Along with the boxes, do two small things that people forget:

• Name the main API calls. For a chat app: sendMessage(chatId, text) and getMessages(chatId, afterTime). Two or three lines is enough.
• Name the main data. "A message has an id, a chat id, a sender, some text, and a time." That one sentence tells the interviewer you know what you are storing.

Then walk one request through the drawing out loud. "The user sends a message. It hits the load balancer, goes to a server, the server writes it to the database, and then pushes it to the other person." If you can walk one request from start to end without hand waving, your boxes are probably right. If you get stuck in the walk, you found a missing box.

Add boxes later only with a reason. "Reads are 100 times more than writes, so I am adding a cache here." Not "and here is a cache because caches are good".

Step 5: Go deep on one or two parts

You cannot go deep on everything. In 45 minutes you can go deep on maybe two things. So pick.

How do you pick? Two easy ways. You can ask: "I think the hardest part here is X. Should I go deeper there, or is there somewhere else you care about?" Interviewers often steer you, which is a gift. Or you pick the part where the numbers hurt most. If storage is huge, go deep on storage. If it is read traffic, go deep on caching. If it is real time delivery, go deep on that.

Going deep means:

• Choose a concrete approach, not a category. Not "I will use a NoSQL database" but "I will store messages keyed by chat id and time, so reading the last 50 messages is one range read".
• Say at least one alternative and why you did not pick it.
• Check it against your numbers. "20,000 writes a second, so one database is not enough, I will split the data by chat id."

This is where most of the marks are. The first half of the interview gets you to a reasonable starting point. The deep dive shows whether you actually understand how things work.

Step 6: Failures and tradeoffs

With the time you have left, poke at your own design before the interviewer does. It looks confident, and it often steals their best questions.

Ask yourself:

• What if this server dies? What if this database dies?
• What is the slowest or most overloaded piece? What happens when traffic doubles?
• What data could be lost, and how bad is that?
• What did I give up with my choices?

Then say the tradeoffs plainly. "I used a cache, so reads are fast, but a user might see a value that is a few seconds old. For a like count that is fine. For a bank balance it would not be." Every choice in system design costs something, and saying the cost out loud is the whole point of this step.

If you still have time, mention what you would do next: monitoring, alerts, how you would roll out a change safely. One or two sentences. No more.

How to split 45 minutes

Here is a split that works. It is a guide, not a rule. If the interviewer wants to spend 20 minutes on one thing, follow them.

The mistake people make is the time shape. They spend 25 minutes on boxes and then have 5 minutes for the deep dive. Watch the clock at minute 10 and minute 20. If you are still on requirements at minute 15, move on.

If the interview is 60 minutes, give the extra time to the deep dive. If it is 30 minutes, squeeze the first two steps into 5 minutes in total and keep one deep dive.

What to do when you get stuck

You will get stuck at some point. Everyone does. The interview is not testing whether you never freeze. It is testing what you do next.

Say it honestly and calmly. "Let me think about this for a moment." Silence for 10 seconds feels long to you and is nothing to them.

Some things you can do:

• Go back to the requirements. Read one out loud and ask which part of the design serves it. Often the next step shows up.
• Go back to the numbers. "We have 20,000 writes a second. What does that break?" Usually it points to the next problem.
• Make the problem smaller. Solve it for one user, then for one thousand, then for a million. The ideas you need appear as the numbers grow.
• Name two options and compare them out loud, even if you are unsure which wins. "I could do A, which is simpler, or B, which scales better. A first, and I would move to B if traffic grows." That is a perfectly good answer.
• Ask for a hint, once. "I am not sure how to keep these two copies in sync. Is there a direction you would like me to take?" Asking is much better than going silent or guessing wildly. Do not ask for hints every five minutes though.

If you realise something earlier was wrong, say so and fix it. "Actually, I put the cache in the wrong place, it should be before the database." Fixing your own mistake calmly is a strong signal. Pretending it did not happen is a weak one.

Common beginner mistakes

Jumping straight to the database. Someone says "design a photo app" and within a minute there is a table with columns on the board. But you do not know yet how many photos, how many users, or what they do. The database choice depends on those. Start with questions and boxes, and choose storage later.

Naming tools with no reason. "I will use Kafka, Redis, Cassandra and Kubernetes." The interviewer asks "why Cassandra?" and the answer is "it scales". That is not a reason. A good answer sounds like: "I need to write 20,000 messages a second and read them by chat id, so I want a store that is good at fast writes and range reads by a key. Something like Cassandra fits. A normal relational database could work at a smaller size." Tools are the last words in the sentence, not the first.

Never checking the numbers. You design a whole system and never once said how big it is. Then you add a cache "to be fast" for a service that gets 10 requests a second. Or you use one database for a system that needs 50,000 writes a second. The estimate takes two minutes and saves the whole design from being random.

Designing for the whole world on day one. If the product has 100,000 users, one good server and one database is a correct answer. Say how it would grow, and stop there. Over building is as wrong as under building.

Talking without drawing. Your drawing is the shared surface. If you talk for three minutes with nothing on the board, the interviewer cannot follow, and you cannot see your own gaps.

Never stating a tradeoff. If every choice you make sounds like it is free, the interviewer will think you do not know what you are giving up. Everything has a cost. Say it.

Going silent while thinking. Think out loud in short sentences. The interviewer cannot give you credit for thoughts they cannot hear.

Treating it like an exam with one right answer. It is a conversation. Ask, check, adjust. If they push back, they are usually helping, not attacking.

A sample opening, said out loud

Here is roughly how the first two minutes can sound. Change the words to your own.

"Before I start, I would like to ask a few questions. Who are the users and what is the main thing they do? ... Okay, so one to one messages only, no groups for now. How many daily active users should I assume? ... Good, 50 million. Does a message ever get lost? ... No, so I will treat delivery as important. Let me write that down as requirements, and then I will do a quick estimate to see how big this is."

Nothing fancy. Short, calm, and it sets up the next ten minutes.

A tiny checklist to keep in your head

• Did I ask about scope and size before drawing?
• Are my requirements written, with something marked out of scope?
• Do I have a rough number for requests per second and storage?
• Does every box on the board exist because of a requirement or a number?
• Did I go deep on one or two parts, with reasons and alternatives?
• Did I say what could break and what I gave up?

If you can say yes to all six, you did the interview well, whatever exact boxes you drew.

Interview questions to check yourself

"Why do you ask clarifying questions before drawing anything?"

Because the question is vague on purpose. Answers about scope and size change the design, and guessing can send you down the wrong path for the whole interview.

"Name one clarifying question and the design choice it affects. "Can users see slightly old data?" If yes, you can use caches and database copies freely. If no, you must be much more careful about keeping data fresh."

"Why do you estimate numbers before picking technology?"

The size tells you what you need. 100 requests a second can run on one server, 100,000 cannot. The number picks the design, not the other way round.

"You are stuck at minute 25. What can you do?"

Say you need a moment, go back to a requirement or a number to find the next problem, compare two options out loud, or ask for one hint. Staying silent is the worst choice.

"Why is "I will use Kafka because it scales" a weak answer?"

It names a tool without a reason that ties to the problem. A good answer states the need first (for example, many writes a second read in order by key) and then says why the tool fits it.