AI InterviewSearch…Search problems, topics, or pages…Ctrl KGet started
Skip to content
SD notes

System Design · Note 15 of 22

How to Answer a System Design Interview

Beginner · 6 min read · updated 14 November 2026

Quick answer

How do you answer a system design interview question?

Work in time-boxed stages. Clarify functional and non-functional requirements and scope, estimate the load, define the API and data model, draw a simple high-level design, then deep-dive into the parts the interviewer cares about, and finish with bottlenecks and trade-offs. Explain every choice by a requirement or a number.

On this page
  1. The stages
  2. Requirements first
  3. API and data model
  4. Build the design up
  5. What interviewers listen for
  6. Common mistakes
  7. Interview questions
  8. Common questions

A system design round is open-ended on purpose. A fixed order of stages keeps the answer complete and leaves time for depth.

The stages

  1. Requirements and scope: functional, non-functional, and what is out.
  2. Estimates: QPS, peak, storage, bandwidth — see Back-of-the-Envelope Estimation.
  3. API: the few endpoints the features need.
  4. Data model: entities, keys, and the store each lives in.
  5. High-level design: boxes and arrows, end to end.
  6. Deep dives: one or two components in detail.
  7. Wrap-up: bottlenecks, failures, trade-offs.
A 45-minute system design interview, stage by stage

Requirements, minutes 0–5: Ask what the system must do, for whom and at what scale, and agree what is out of scope. Nothing is drawn yet.

0:01 / 0:20Step 1 of 7
Transcript · 7 steps

Requirements first

  • Functional: what users can do.
  • Non-functional: latency, availability, durability, consistency, scale.
  • Out of scope: say it and write it down.
  • Ask about users, scale, read/write mix and the one feature that matters most.
Requirements sorted: functional, non-functional, out of scope

Interview: "Design a photo-sharing app." Requirements come first; here is the first one heard: "Upload a photo".

0:01 / 0:21Step 1 of 8
Transcript · 8 steps

API and data model

  • One endpoint per functional requirement; method, path, inputs, outputs.
  • Page large lists with a cursor.
  • Pick each store by how its data is read, not by habit.
From requirements to endpoints to tables

Each functional requirement becomes one endpoint, and each endpoint names the data it reads or writes. Nothing else is invented.

0:01 / 0:10Step 1 of 4
Transcript · 4 steps

Build the design up

  • Start with client → server → database; check every requirement has a path.
  • Add each component only for a reason: a number, a requirement, a failure.
  • Name the trade-off as you add it ("a cache makes the feed slightly stale").
The design grows from one box, one reason at a time

Start with the simplest design that meets the functional requirements: a client, one app server, one database.

0:01 / 0:15Step 1 of 5
Transcript · 5 steps

What interviewers listen for

  • Structure: you lead the conversation through the stages.
  • Reasons: each box ties to a requirement or a number.
  • Trade-offs: consistency vs availability, cost vs latency, simplicity vs scale.
  • Depth: at least one component explained down to data and failure handling.
  • Collaboration: you check in and take hints.

Common mistakes

  • Drawing before asking: the design answers a question nobody asked.
  • Components with no reason: a queue, Kafka or sharding "because scale".
  • Product names instead of mechanisms: say what Redis does here, not just "Redis".
  • No failures: every box can die; say what happens when it does.
  • One corner in depth, the rest unfinished.

Interview questions

  • What do you do in the first five minutes? Clarify features, scale, latency and availability targets, and agree what is out of scope.
  • When do you estimate? Right after requirements, and only the numbers that change a decision.
  • How do you choose what to deep-dive into? The hardest or hottest part — the read path, the data model at scale — or what the interviewer asks.
  • How do you end? List bottlenecks and failure modes and what you would improve next.

Next: Design a Chat App · Before this: Back-of-the-Envelope Estimation

Common questions

How long should each part of a system design interview take?

In a 45-minute round a common split is about five minutes on requirements, a few each on estimates, API and data model, ten on the high-level design, ten to fifteen on deep dives and five to wrap up. Adjust it to what the interviewer steers towards.

What do system design interviewers look for?

Clear requirements before drawing, numbers that drive decisions, a simple working design first, trade-offs said out loud, and depth in at least one component. They also watch how you take hints and change course.

Should I start drawing the architecture immediately?

No. Spend the first minutes on requirements and scale. A design drawn before knowing the read-to-write ratio, the latency target or what is out of scope often has to be thrown away.

What are common mistakes in system design interviews?

Jumping to a design, adding components without a reason, naming technologies instead of explaining them, ignoring failures and trade-offs, and spending all the time on one corner while the end-to-end design stays unfinished.

How do I handle a part of the design I do not know?

Say what you know, reason from first principles and state the trade-off you would test. Interviewers value a clear line of reasoning more than a memorised product name.

AI InterviewGet started

How to Answer a System Design Interview, Step by Step

A time-boxed framework for system design interviews: requirements, estimates, API, data model, high-level design, deep dives and wrap-up, animated.

  • Subject: System Design
  • Level: Beginner
  • Reading time: 6 min
  • Updated: 2026-11-14

How do you answer a system design interview question?

Work in time-boxed stages. Clarify functional and non-functional requirements and scope, estimate the load, define the API and data model, draw a simple high-level design, then deep-dive into the parts the interviewer cares about, and finish with bottlenecks and trade-offs. Explain every choice by a requirement or a number.

A system design round is open-ended on purpose. A fixed order of stages keeps the answer complete and leaves time for depth.

The stages

  1. Requirements and scope: functional, non-functional, and what is out.
  2. Estimates: QPS, peak, storage, bandwidth — see Back-of-the-Envelope Estimation.
  3. API: the few endpoints the features need.
  4. Data model: entities, keys, and the store each lives in.
  5. High-level design: boxes and arrows, end to end.
  6. Deep dives: one or two components in detail.
  7. Wrap-up: bottlenecks, failures, trade-offs.
0 min15 min30 min45 minRequirements5Estimates4API4Data model4High-level design10Deep dives13Wrap-up5
A 45-minute system design interview, stage by stage.
  1. Requirements, minutes 0–5: Ask what the system must do, for whom and at what scale, and agree what is out of scope. Nothing is drawn yet.
  2. Estimates, minutes 5–9: Turn the scale into QPS, storage and bandwidth — only the numbers that will change a decision.
  3. API, minutes 9–13: Write the few endpoints the functional requirements need: method, path, inputs, outputs.
  4. Data model, minutes 13–17: Name the entities, their keys and the store each lives in, chosen by how it is read.
  5. High-level design, minutes 17–27: Draw the boxes end to end so every requirement has a path through them; keep it simple first.
  6. Deep dives, minutes 27–40: Go deep on the one or two parts the interviewer cares about: the hot path, the hard data problem.
  7. Wrap-up, minutes 40–45: Name bottlenecks, failure modes and trade-offs, and what you would do with more time.

Requirements first

  • Functional: what users can do.
  • Non-functional: latency, availability, durability, consistency, scale.
  • Out of scope: say it and write it down.
  • Ask about users, scale, read/write mix and the one feature that matters most.
FunctionalNon-functionalOut of scopenext requirementUpload a photoFeed loads < 200 msFollow another userComments and DMsPhotos are never lostSee a feed of followsHighly available reads
Requirements sorted: functional, non-functional, out of scope.
  1. Interview: "Design a photo-sharing app." Requirements come first; here is the first one heard: "Upload a photo".
  2. "Upload a photo": It is something a user does, so it is functional.
  3. "Feed loads < 200 ms": A latency target says how well, not what: non-functional, and it will call for caching.
  4. "Follow another user": Following is a feature, so it joins the functional list.
  5. "Comments and DMs": Agreed out of scope for this interview, written down so the design does not drift into it.
  6. "Photos are never lost": Durability is a quality, not a feature: it will mean replicated storage.
  7. "See a feed of follows": The feed is the core read, the third functional requirement.
  8. Availability over strict freshness for the feed: a non-functional choice that shapes replication. Sorted: 3 functional, 3 non-functional, 1 out of scope — confirm the list before drawing.

API and data model

  • One endpoint per functional requirement; method, path, inputs, outputs.
  • Page large lists with a cursor.
  • Pick each store by how its data is read, not by habit.
requirementendpointdataUpload a photoPOST /photosphotos(id, owner, url)Follow another userPOST /followsfollows(follower, followee)See a feed of followsGET /feed?cursor=reads follows → photos
From requirements to endpoints to tables.
  1. Each functional requirement becomes one endpoint, and each endpoint names the data it reads or writes. Nothing else is invented.
  2. "Upload a photo" becomes POST /photos, which writes photos.
  3. "Follow another user" becomes POST /follows, which writes follows.
  4. "See a feed of follows" is GET /feed, paged by a cursor; it reads the other two tables. Two tables answer all three requirements.

Build the design up

  • Start with client → server → database; check every requirement has a path.
  • Add each component only for a reason: a number, a requirement, a failure.
  • Name the trade-off as you add it ("a cache makes the feed slightly stale").
ClientApp server× 9Database≈ 3.5K reads/sLoad balancerCacheObject storeCDNpullQueueWorker
The design grows from one box, one reason at a time.
  1. Start with the simplest design that meets the functional requirements: a client, one app server, one database.
  2. The estimate says about 17.4K reads a second at peak. At an assumed 2K per server that is 9 app servers behind a load balancer.
  3. Reads repeat, so a cache goes in front of the database. At an assumed 80% hit ratio the database sees about 3.5K reads a second instead of 17.4K.
  4. Photo bytes leave the database: they go to object storage, and a CDN serves the 8.7 GB/s of peak views from its edges.
  5. Thumbnails need not hold up an upload, so the app queues the work and a worker does it. Every box now traces back to a requirement or a number.

What interviewers listen for

  • Structure: you lead the conversation through the stages.
  • Reasons: each box ties to a requirement or a number.
  • Trade-offs: consistency vs availability, cost vs latency, simplicity vs scale.
  • Depth: at least one component explained down to data and failure handling.
  • Collaboration: you check in and take hints.

Common mistakes

  • Drawing before asking: the design answers a question nobody asked.
  • Components with no reason: a queue, Kafka or sharding "because scale".
  • Product names instead of mechanisms: say what Redis does here, not just "Redis".
  • No failures: every box can die; say what happens when it does.
  • One corner in depth, the rest unfinished.

Interview questions

  • What do you do in the first five minutes? Clarify features, scale, latency and availability targets, and agree what is out of scope.
  • When do you estimate? Right after requirements, and only the numbers that change a decision.
  • How do you choose what to deep-dive into? The hardest or hottest part — the read path, the data model at scale — or what the interviewer asks.
  • How do you end? List bottlenecks and failure modes and what you would improve next.

Next: Design a Chat App · Before this: Back-of-the-Envelope Estimation

Common questions

How long should each part of a system design interview take?

In a 45-minute round a common split is about five minutes on requirements, a few each on estimates, API and data model, ten on the high-level design, ten to fifteen on deep dives and five to wrap up. Adjust it to what the interviewer steers towards.

What do system design interviewers look for?

Clear requirements before drawing, numbers that drive decisions, a simple working design first, trade-offs said out loud, and depth in at least one component. They also watch how you take hints and change course.

Should I start drawing the architecture immediately?

No. Spend the first minutes on requirements and scale. A design drawn before knowing the read-to-write ratio, the latency target or what is out of scope often has to be thrown away.

What are common mistakes in system design interviews?

Jumping to a design, adding components without a reason, naming technologies instead of explaining them, ignoring failures and trade-offs, and spending all the time on one corner while the end-to-end design stays unfinished.

How do I handle a part of the design I do not know?

Say what you know, reason from first principles and state the trade-off you would test. Interviewers value a clear line of reasoning more than a memorised product name.

← Back-of-the-Envelope Estimation · Design a Chat App (WhatsApp) →