Everyday storyA cooking contest with a clock
In a cooking contest, the judges say "make a dessert" and start a 45-minute clock. The cooks who do well don't start whisking straight away. They ask: for how many people? Any allergies? Does it need to travel, or will it be eaten here? Then they plan out loud: the base first, the filling next, the garnish last. With fifteen minutes left, their dessert is already edible, and they spend the rest making it better.
The cook who spent 40 minutes on a perfect sugar sculpture and has no cake at the end goes home, however beautiful the sculpture. So does the cook who rushed a cake, never tasted it, and served it with a raw middle. The judges are not only eating the dessert. They're watching how each cook used the clock, which problems they noticed, and what they did about them.
A system design round works the same way. The question is wide open, the clock is fixed, and the person across the table is watching the process as much as the result. A plan you've practised many times is what keeps you from building the sugar sculpture.
In a real productA system design round at a product company
Many companies in India and abroad ask experienced engineers, and more and more freshers, to "design" an app they already know: a URL shortener, a chat app, a food delivery tracker, a train-ticket booking site. There's no single right answer. The interviewer watches how you get to an answer: what you ask, what you assume, what you build first and how you improve it. The round is usually 45 to 60 minutes, over a whiteboard in person or a shared drawing tool on a video call.
Candidates who've been through a few of these say the same things. The question felt too big at first. The minutes went far faster than expected. And the rounds that went well were the ones where they kept the conversation moving, not the ones where they knew the most facts. One common piece of feedback after a rejection is "jumped into details too early" or "didn't finish a working design". Both are clock problems, not knowledge problems, and both are fixed by a plan.
The ideaHow it works
Why a plan beats talent here
A is a strange exam. The question is vague on purpose, there's no answer sheet, and you have about the length of a lunch break to show how you think. Without a plan, most people do one of two things. They freeze, staring at the board, waiting for an idea. Or they rush, drawing the first architecture that comes to mind and then defending it for 40 minutes.
A fixed plan solves both. You always know what to do next, so you never freeze. And because the plan starts with questions and numbers, you never rush into the wrong design. The plan also makes you easy to grade. The interviewer has a with boxes for requirements, estimates, design, depth and trade-offs; if you visit each step clearly, they can tick each box with evidence.
The six steps and the clock
Use the same plan every time, so the clock never surprises you:
- Requirements (5 minutes). Ask what the system must do and for whom. Agree on two or three core and say out loud what you'll leave out. Then ask about the : how many users, how fast, how reliable, how fresh.
- Estimates (5 minutes). Turn "lots of users" into numbers with maths: at the busiest time, and how much data a year. This tells you whether one is enough or whether something will break.
- API and data (5 minutes). Name the main calls, like
POST /linksandGET /{code}, and sketch the : the two or three main tables or records and their key fields. This pins down what the boxes must do. - High-level design (15 minutes). Draw the simplest that works: , , a database. Walk one request through it. Then grow it to meet your numbers.
- Deep dives (10 minutes). Pick the hardest part, often where your estimate says something will break, and go deeper. This is the .
- Trade-offs and wrap-up (5 minutes). Say what your choices cost, what you'd change if the numbers changed, and what you'd build next.
Notice the shape. The first 15 minutes produce no boxes at all, only words and numbers. That feels slow, but it's what makes the next 30 minutes count. And the design is "done", in a simple form, by the half-way point. Everything after that is improvement.
For a 60-minute round, stretch the middle, not the start: keep requirements and estimates at about 5 minutes each, give the high-level design 20, and give deep dives 20. The extra time goes where the marks are.
Here is the whole round as a conversation:
- 1
YouInterviewer
Minutes 0–5: what must it do, for how many people?
- 2
InterviewerYou
Answers, and sets the limits
- 3
YouWhiteboard
Minutes 5–10: rough numbers
- 4
YouWhiteboard
Minutes 10–15: the main API calls
- 5
YouWhiteboard
Minutes 15–30: boxes and arrows, simple first
- 6
InterviewerYou
Minutes 30–40: what if this part breaks?
- 7
YouInterviewer
Minutes 40–45: trade-offs and what you would do next
What each step leaves on the board
A good habit is to make each step leave something visible behind. If the interviewer glances at the board at minute 20, they should be able to read your whole story without asking.
- After requirements: a short list, split into "must do" and "how well", plus a line saying what's out of scope.
- After estimates: three or four numbers with units, such as "peak 3,000 reads a second, 30 writes a second, 300 GB a year".
- After the API: four to six lines like
POST /ordersandGET /orders/{id}/tracking, each with its main inputs. - After the design: boxes with labelled arrows, and one request traced through them.
- After deep dives: the improved part drawn bigger or off to the side, with the numbers that justify it.
Leaving the board in this state does two things. It keeps you honest: if an estimate is on the board, you're more likely to use it. And it helps the interviewer, who is writing notes while you talk and can copy straight from what they see.
Start simple, then grow on purpose
The hardest habit for strong engineers is drawing the simple version first. You know that a real food-delivery app has dozens of services, so drawing three boxes feels naive. Draw them anyway. A simple design that works is the foundation; it proves you understand the flow of one request. Then use your numbers to grow it one step at a time, saying why each step is needed:
- "One app server handles about 1,000 to 2,000 requests a second; we need 6,000 at peak, so I'll put a in front of several servers."
- "Ninety per cent of requests are reads of the same popular items, so a in front of the database takes most of that load."
- "Writes are 40,000 a second, which no single ordinary database will take, so this is where I'll go deep."
Each step names the , the number that proves it, and the fix. That's very different from drawing a cache "because big systems have caches". Interviewers can tell the difference within a minute.
Driving the conversation
Signpost. Say where you are and where you're going: "I've got the requirements; let me do quick numbers." "That's the simple version; now let me check it against the peak." The interviewer can then steer, but you're never waiting to be told what to do.
Think out loud. A quiet candidate gives the interviewer nothing to write down. If you're weighing two options, say both and why you're leaning one way. Even "I'm not sure yet; let me finish the write path and come back to it" is useful evidence of how you work.
Check in, briefly. Every few minutes, ask a short question: "Does that scope sound right?" or "Would you like me to go deeper on storage or on the live updates?" This turns a monologue into a design discussion, and it often reveals what the interviewer wants to see.
Treat hints as gifts. If the interviewer asks "what happens if this server dies?", they're not attacking you; they're pointing at a gap. Take the hint, fix the gap, and thank them for it in how you respond, not with flattery.
Choosing your deep dives
Deep dives are where most of the marks for experienced candidates are, so choose them well. Good candidates come from three places:
- Where your numbers say something breaks. A component above its limit at peak is the most natural deep dive.
- Where the product is unusual. For a ticket booking site, it's two people grabbing the same seat. For a chat app, it's delivering messages to someone who is offline.
- Where failure is costly. Payments, anything involving money, and data people can't afford to lose.
Offer two choices and let the interviewer pick: "The two hard parts I see are the location writes and the live updates to customers. Which would you like first?" That shows judgement and hands them the steering wheel without giving up the plan.
The big idea: have a working, simple design by the half-way mark, then spend the rest of the time making it better and explaining why.
For experienced engineers
Expectations rise with seniority. Freshers are mostly judged on clear requirements and a sensible high-level design; prompting from the interviewer is expected. Mid-level candidates should reach the design with little help and handle one solid deep dive. Senior and staff candidates are expected to lead the whole session, pick deep dives that matter for the business, and discuss failure modes, operability (deploys, monitoring, on-call), cost, migration from the current system, and how they'd stage the build. The plan doesn't change; the share of time after minute 30, and how much you drive it unprompted, does. A useful self-check while practising: record yourself, then mark each minute as requirements, numbers, design, depth or trade-off. If more than 10 of 45 minutes are unlabelled, that's time the interviewer couldn't grade.
Step by stepArjun designs a food-delivery tracker, minute by minute
Arjun is told: "Design the live order-tracking screen for a food-delivery app." He has 45 minutes. Here's how his plan plays out.
-
Minutes 0–5: requirements. Arjun asks which side to focus on: the customer's screen. He confirms three features: show the order's status (accepted, cooking, picked up, delivered), show the rider moving on a map, and show an . He says out loud: "I'll leave out payments, restaurant search and how riders are assigned." Scale: the interviewer says 20 lakh orders a day, mostly in Indian cities, with a dinner peak.
-
Minutes 5–10: estimates. He writes:
- Peak hour carries about 15% of the day: 3 lakh orders.
- Each order is live for about 40 minutes, so about 2 lakh orders are active at once at peak.
- Each rider sends a every 5 seconds: 2 lakh ÷ 5 = 40,000 location writes a second.
- Customers watching: say half of them, refreshing every 10 seconds: about 10,000 reads a second.
- Each ping is about 100 bytes. A day is roughly 100 crore pings, about 100 GB.
He says the one sentence that matters: "Writes are the hard part, not reads or storage."
-
Minutes 10–15: API and data.
POST /riders/{id}/locationwith position and time.GET /orders/{id}/trackingreturning status, rider position and ETA. An orders table with order ID, status, rider ID and timestamps; a separate "latest position" record per rider. -
Minutes 15–22: simple design. Apps talk to app servers through a load balancer; servers read and write one database. He traces one ping and one customer refresh through it.
-
Minutes 22–30: grow it. He checks the numbers: 40,000 writes a second would swamp one database. So the latest position goes into an in-memory location cache, overwritten every 5 seconds, and only order status changes go to the database. Status changes are rare and important, so they trigger a .
-
Minutes 30–40: deep dive. The interviewer picks the location path. Arjun explains why losing a cache node is survivable (every rider resends in 5 seconds, so the map heals itself), how to split riders across cache nodes by rider ID, and why he'd move from 10-second to a only if refresh traffic grew.
-
Minutes 40–45: trade-offs. "The map can be up to 5 seconds behind, which customers accept. I'm not keeping full route history in the main database; if support needs it, I'd write sampled pings to cheap storage. Next I'd work on the ETA."
At no point did Arjun have the "best" design. But at every minute, the interviewer knew where he was and why.
What happens when…Situations
Real situations this idea runs into, and how well-built systems handle each one.
What happens when the interviewer interrupts with a detailed question at minute 8
You're halfway through your estimates and the interviewer asks, "How exactly would you store the rider locations?" If you dive in fully, you'll spend 15 minutes on one box and run out of time before the design exists. If you refuse, you seem rigid, and you might miss what they actually want to see.
Give a one-line answer, write the topic on a "deep dives" list in the corner of the board, and ask to finish the outline first. Most interviewers say yes. If they insist, go deep now: they're telling you what they care about, and the plan bends to them.
- 1
InterviewerYou
Minute 8: how exactly will you store rider locations?
- 2
YouInterviewer
Short answer: keep only the latest position in memory
- 3
YouWhiteboard
Adds "location store" to the deep-dive list
- 4
YouInterviewer
Shall I finish the outline first and come back to it?
- 5
InterviewerYou
Yes, carry on
- 6
YouWhiteboard
Minute 32: picks it up as the first deep dive
What happens when you reach minute 35 with no complete design
This is the most common way to fail a round. Usually the time went on requirements that became a long product discussion, or on estimates worked to three decimal places. There's no time for deep dives or trade-offs, and those are the parts experienced candidates are mostly graded on.
Glance at the clock at minutes 10, 20 and 30, and say where you are. If you're behind at minute 20, say so and cut: "I'll draw the simplest version now and refine it." A rough complete design always scores better than a beautiful half of one.
What happens when you're asked to design something you've never seen
You prepared chat apps and URL shorteners, and the question is "Design a parking-lot booking system for a mall chain" or "Design the system behind a lift that 30 floors share". Panic makes people forget their plan, because nothing they memorised fits.
The plan doesn't depend on the problem. Ask what it must do, estimate the scale (often surprisingly small: a mall chain might have 100 malls and a few bookings a second), write the API, draw the simple design. Unfamiliar problems often reward basics: a clear data model, correct handling of two people booking the same spot, and honest numbers.
What happens when you realise half-way that your design is wrong
At minute 25 you notice your design stores every chat message in one table that will grow by crores of rows a day, and your estimate says that won't work. Many candidates hide it and hope. Others panic and wipe the board.
Say it plainly: "Looking at my numbers, this table won't hold up. Let me change it." Then change only the part that's wrong. Catching your own mistake with your own estimate is strong evidence, not a weakness. Interviewers trust candidates who check their work.
What happens when the interviewer stays almost completely silent
Some interviewers say little on purpose, to see whether you can lead. Others are simply quiet people. Either way, there are no hints, no nods and no clue whether you're on track, and many candidates slow down and start asking "is this what you want?" every minute.
Lean harder on your plan. Signpost each step, state assumptions instead of waiting for answers, and offer choices: "I'll go deep on the write path unless you'd rather see something else." Silence usually means "carry on"; your plan gives you something to carry on with.
Watch outCommon mistakes
Drawing boxes in the first minute
The question is "Design Instagram" and within thirty seconds there's a load balancer, three services and a on the board. It looks confident, but nothing is anchored. When the interviewer asks "why a queue?", there's no requirement or number to point to, and the whole design starts to look memorised.
Spend the first 10 minutes on questions and numbers, even when you know the problem well. Then every box you draw has a reason you can point to on the board: "this queue is here because uploads peak at 5,000 a second and processing takes 2 seconds each".
Naming products instead of explaining parts
"I'll use Kafka, Redis, Cassandra and Elasticsearch." Brand names can sound impressive, but they hide whether you know what each part does and why it's needed. Interviewers often follow up with "why that one?", and a candidate who memorised a stack can't answer.
Describe the role first: "a durable queue so uploads aren't lost when workers are busy", "an in-memory cache for the latest positions". Name a product only if asked, or as an example, and be ready to say what property you need from it.
Going deep on the part you know best
A candidate who knows databases well spends 15 minutes on for the user table, which serves 50 requests a second, while the real problem is 40,000 location writes a second. It shows knowledge, but it also shows poor judgement about what matters.
Let your estimates choose the deep dive. If you want to show a strength, link it to the bottleneck: "the write path is the hard part, and here's how I'd lay out that storage".
Talking for ten minutes without checking in
Some candidates treat the round as a lecture. They may be right, but the interviewer had a hint ready at minute 12 that would have saved five minutes, and never got a chance to give it. A long monologue also makes it harder for them to steer you to the parts they need to grade.
Pause at the end of each step with a short check: "Does that scope look right?" "Shall I go deeper on X or Y?" Thirty seconds of checking can save ten minutes of drifting.
Interview angleIn an interview
This whole lesson is the interview, but the plan itself is also something interviewers notice and sometimes ask about directly: "How would you approach this?" or, at the end, "If you had more time, what would you do?" Your answer shows whether you work to a method or improvise.
A strong round shows:
- requirements agreed and scope stated in the first five minutes;
- numbers on the board, and the design visibly using them;
- a working simple design by about minute 30;
- growth step by step, each step tied to a bottleneck;
- one or two deep dives on the hardest parts, chosen with the interviewer;
- a clear close: trade-offs, what you'd change at ten times the scale, what you'd build next.
Follow-up: "We only have 30 minutes today. How would you change your approach?" Keep requirements and estimates short, about three minutes each, skip the detailed API, get the design up by minute 15 and offer one deep dive.
Follow-up: "If you had another hour, what would you do?" Name the next most important risk from your own design, such as handling a outage, monitoring, or cost at peak, and say how you'd tackle it, rather than adding random features.
Follow-up: "Why didn't you start with ?" Because the requirements didn't need them yet. Start with the simplest design that meets the numbers, and split services when a real limit, like team size or different scaling needs, appears.
Try it in the simulator
Goal: Find what breaks first when your simple design meets peak traffic.
This is a typical first sketch: users, one app server, one database. Press Run: at 50 requests a second it's fine. Now select Users, set Requests per second to 2,000 and run again. Which part reaches 100% first? That's the deep dive you'd offer the interviewer. Fix it, and run once more.
Hint
The app server tops out at about 1,800 requests a second. Put a load balancer in front and add more app servers behind it, then say why that works: the servers share the load, and none of them keeps anything the others need.
Quick checkCheck your understanding
Words in this lessonThe jargon, in plain English
Every technical word used above. In the lesson, tap any word with an ⓘ to see its meaning right there.
- API
- An Application Programming Interface: an agreed set of requests one program can send another, and the responses it will get.
- Back-of-the-envelope estimate
- A quick, rounded calculation, like 1 crore requests a day ≈ 100 a second, used to decide which parts of a design matter. Close enough beats exact.
- Bottleneck
- The part of a system that limits everything else, like the narrow neck of a bottle.
- Cache
- A fast store that keeps copies of frequently used data so you don't have to fetch it from the slow source every time.
- Client
- Whatever sends requests: a browser, a mobile app, or another service.
- Data centre
- A building full of servers, with its own power and cooling. Big apps run in several, often in different cities.
- Data model
- The main kinds of records a system stores and the key fields of each, such as an orders table with an order ID, status and rider ID. It's sketched before the boxes so you know what each part must keep.
- Database
- A program that stores data safely and lets you query it, even after restarts and crashes.
- Deep dive
- The part of a design interview where you zoom in on one hard piece of the system, such as where the load is heaviest, and work out its details and failure cases.
- ETA
- Estimated time of arrival: how long until the driver, the food or the train reaches you.
- Functional requirement
- Something the system must do, such as "people can send a message" or "opening a short link redirects you".
- GPS ping
- A phone telling the server where it is right now, sent every few seconds by a driver's or delivery partner's app.
- High-level design
- The big-picture drawing of a system: its main parts as boxes and the requests between them as arrows, without the fine detail inside each part.
- Index
- A data structure a database keeps alongside a table so it can find matching rows without reading every row.
- Load balancer
- A component that receives requests and spreads them across several servers.
- Message queue
- A buffer that holds messages until a consumer is ready to process them, so producers don't have to wait.
- Microservice
- A small, separate program that does one job (payments, search, delivery) and talks to the others over the network.
- Non-functional requirement
- How well the system must do its job: how fast, for how many people, how reliably, and how fresh the data must be.
- Polling
- Asking the server again and again, every few seconds, whether anything has changed.
- Push notification
- A message the app's server sends to your phone even when the app is closed, like "Your order is on the way".
- Requests per second (rps)
- How many requests arrive at, or are handled by, a system every second.
- Rubric
- The list of areas an interviewer scores you on, each with a scale and notes on what a strong answer looks like.
- Server
- A computer (or program) that waits for requests and answers them.
- Stateless server
- A server that keeps no user-specific memory between requests, so any copy of it can answer any request.
- System design interview
- A job interview round, usually 45 to 60 minutes, where you design a large app out loud on a whiteboard. It tests how you reason, not whether you remember one right answer.
- WebSocket
- A long-lived, two-way connection between client and server, used for live updates like chat or delivery tracking.
Enjoyed this? Keep going for free
This lesson is a free preview. Sign up free to save your progress and earn XP, and to unlock all 232 lessons, the simulator challenges and mock interviews.
Sign up free