“Design a URL shortener.” The timer starts. Most candidates pick up the pen and draw a load balancer within the first minute. Twenty minutes later they are deep inside database indexes, the interviewer has asked twice about traffic, and nobody has agreed what the system is supposed to do.
They knew the components. They lost the clock. Most failed design rounds go this way: not a gap in knowledge, but boxes drawn before requirements, or one component polished while the rest of the system waits.
A framework fixes the clock. This lesson gives one, with a time box for each step and what the interviewer scores along the way. Use it for product and infrastructure design rounds. Skip it for low-level or object-oriented design rounds, which ask about classes rather than services.
- You have built or maintained a backend service that talks to a database.
- The system design building blocks map helps, but you can read it after this lesson.
- The round scores your process: questions, trade-offs and collaboration matter more than the final diagram.
- Six steps in a fixed order: requirements, entities, API, high-level design, deep dives, wrap-up.
- Get a simple design working end to end before optimising any part of it.
- Estimate only when a number changes a decision.
- Seniority changes who drives: mid-level candidates follow the interviewer, senior candidates lead.
Run the six steps on an unseen prompt, keep each one inside its time box, and explain what the interviewer is looking for at every stage.
What the Interviewer Is Scoring#
Start with the grader, because it changes how you spend the time. Interviewers listen for four things: a working grasp of the fundamentals, questions that pin down the constraints, decisions explained through trade-offs, and a view of the whole system and the people using it. Deep expertise in one database is not on that list.
The final diagram matters less than how you got there. A tidy diagram reached in silence scores lower than a rough one reached by asking good questions. So think out loud, check in at each step, and treat the interviewer as a teammate who knows things about the problem that you do not.
Drawing a load balancer in the first minute, then working in silence until asked a question.
Asking two or three scoping questions, writing the answers down, and reading them back before drawing anything.
The Six Steps on One Clock#
Prep guides split the round into anywhere from three to six steps, but they agree on the order. This course uses six, because each one produces something you can point at on the whiteboard. The table gives a time box for each in a 45-minute round.
Before you look: which step deserves the most minutes? Most people guess requirements. Check the table.
| Step | Minutes | What you produce | What it shows the interviewer |
|---|---|---|---|
| 1. Requirements | ~5 | Top 3 features, 3–5 quantified qualities | You scope before you build |
| 2. Core entities | ~2 | A short list: Url, User | You can name the data |
| 3. API | ~5 | A handful of endpoints | You think from the caller’s side |
| 4. High-level design | 10–15 | Boxes and arrows that serve every endpoint | You can make it work |
| 5. Deep dives | 10–15 | Two or three hardened components | You can make it work well |
| 6. Wrap-up | 3–5 | Bottlenecks, failure cases, next-scale changes | You know its limits |
Take the middle of each range and the plan uses 43 minutes, leaving two for introductions and your questions at the end. The answer to the prediction: building the design and hardening it share most of the clock. Requirements matter enormously, but they should take five minutes, not fifteen.
Steps 1–3: Scope It#
Requirements. Split them in two:
- Functional requirements are the features, phrased as “users can…”: users can shorten a URL, users are redirected when they open it. Keep the top three. Say aloud what you are leaving out.
- Non-functional requirements are qualities: latency, availability, consistency, scale. Put a number on each where you can, the way production teams write SLOs (Google SRE book). Those numbers decide which parts of the system you harden later in the deep dives.
Spend no more than five minutes here.
Entities and API. List the nouns the system stores, then write one endpoint per functional requirement. It is small, but it fixes the vocabulary for the rest of the round. For a URL shortener that is two lines:
POST /urls { longUrl } -> { code }
GET /{code} -> 302 redirect to longUrlSteps 4–6: Make It Work, Then Make It Better#
High-level design. Walk the endpoints one at a time and add only the components each one needs. Client, service, database. That is enough for a first draft. The goal is a design that works end to end, even if it would fall over at scale.
Deep dives. Now return to the non-functional requirements and harden the design against them. If redirects must be fast, this is where a cache appears. If writes are heavy, this is where you discuss sharding. Pick the two or three areas the requirements stress most, and ask the interviewer which they would like to see.
Wrap-up. Name the bottlenecks, the failure cases and what you would change at ten times the load. If you need a checklist, run through the six pillars of the AWS Well-Architected Framework: operations, security, reliability, performance, cost and sustainability. Never call the design perfect. Interviewers hear that as a missing sense of trade-offs.
Starting the deep dive before the high-level design works end to end. An interviewer cannot credit a perfect cache in front of a system that cannot yet serve a request.
Say what you are weighing out loud (“I am choosing between a cache and a read replica”) and ask which matters more to them. If the interviewer challenges a choice, treat it as a new requirement, not an attack: restate it, adjust the design, and name what the change costs.
When to Estimate#
Many guides open the round with back-of-envelope maths: requests per second, storage per year, bandwidth. Others fold rough estimates into the high-level design, or skip them unless a number changes the design.
The last approach holds up best under the clock. Why? Five minutes of arithmetic that ends in “so we need a database” spends time and changes nothing. A good habit is to tell the interviewer you will estimate when a decision depends on a number, then do it at that point. Total storage, for example, decides whether one database is enough or whether you need to shard. With assumed numbers for a URL shortener:
100M URLs/month x ~500 B per row ≈ 50 GB/month
50 GB x 12 months ≈ 600 GB/year
-> one database holds years of data; shard laterThirty seconds, one decision made. The next lesson covers how to do that maths quickly.
Who Drives Depends on Your Level#
Entry-level roles rarely include a system design round. At senior level it is standard, and expectations move with the level.
- Mid level: the interviewer sets the direction and pace. Covering the basics well is enough.
- Senior: you are expected to drive. Move through the first four steps quickly, then propose the deep dives instead of waiting to be asked.
- Staff and above: drive, and widen the frame. Raise cost, failure across regions, operability and what to build first, before the interviewer does.
What Changed in 2026#
AI assistants are entering interview loops, unevenly and fast. In July 2025, 404 Media reported that Meta would let some coding candidates use an AI assistant (404 Media). In May 2026, Business Insider reported a Google pilot that lets junior and mid-level candidates on select US teams use Gemini in a coding round (Shopifreaks).
Both reports are about coding rounds. Rules for design rounds differ by company and keep changing. So ask your recruiter, in writing, which tools each round allows. Practise the framework both ways: with an assistant drafting boilerplate, and alone at a whiteboard.
The prompts themselves are changing too. Classic problems now come with twists such as cost, abuse or an AI feature. An LLM feature, such as a support chatbot, document search or a summariser, fits naturally inside a “design X” question. The framework stays the same. The requirements step just gains two questions:
- What is the latency budget, given a model call that can take seconds?
- What does each request cost, and who pays for it?
Treat the model like any slow, expensive and occasionally wrong dependency, then harden it in the deep dive. The LLM system design interview guide walks through that answer layer by layer.
Try It: The Five-Minute Requirements Drill#
Set a timer for five minutes. The prompt is “Design Pastebin”: users paste text and get a link to share it. Write down:
- Three functional requirements, each starting with “users can…”.
- One thing you will explicitly leave out of scope.
- Three non-functional requirements, each with a number.
Stop when the timer ends, even if you are not finished. Then compare with the model answer.
Hint
Ask which actions a user takes on the first day. Then ask which of them happens most often: the read or the write. That ratio shapes most of the non-functional list.
One reasonable answer
Functional
- Users can paste text and get a short link back
- Users can open a link and read the paste
- Users can set an expiry on a paste
Out of scope
- Accounts, editing, syntax highlighting
Non-functional
- Reads far outnumber writes (assume 10:1)
- A paste opens in under 200 ms for most readers
- A saved paste is never lost before it expires (durability)Your numbers can differ. What matters is that each one is stated, so the interviewer can agree or correct it, and that the read-heavy ratio points you toward caching later.
Two follow-ups arrive in almost every round once the design works: “What happens when this component fails?” and “What changes at ten times the traffic?” Have one sentence ready for each before the wrap-up. And when the interviewer goes quiet after the prompt, that silence is a test of how you handle ambiguity: read your scoping questions back, “So we are building X for Y users, optimising for Z. Shall I start with the API?”
1.You have 10 minutes left and no deep dive yet. What do you do?
Ask the interviewer which component they most want to see hardened, spend about seven minutes on it, then use the last three on bottlenecks and wrap-up.
2.When is a back-of-envelope estimate worth doing?
When its result changes a decision, such as whether the data fits on one database or whether a cache is needed. Otherwise it spends time without moving the design.
3.Why get a simple design working before adding a cache or sharding?
The round scores whether the system works first and whether it scales second. Optimising a part of a system that cannot yet serve a request earns little credit.
Run the drill above on a new prompt every day this week (a chat app, a file store, a news feed) with a timer. On day three, try it without looking at the table. The order of the steps sticks after a few timed runs, not after rereading.
In One Picture#
Scope it requirements · entities · API 12 min
Make it work high-level design 13 min
Make it better deep dives 13 min
Know its limits wrap-up 5 minConclusion#
The six steps are requirements, entities, API, high-level design, deep dives and wrap-up, on a clock of about 5, 2, 5, 13, 13 and 5 minutes, with two to spare. They exist to make your thinking visible, and that is what the round grades. Practise the order until it is automatic, so that in the room your attention goes to the problem instead of to what comes next.
Which step do you usually run out of time on? Tell us in the comments.
- Know the components first: the system design building blocks map shows when each one earns its place.
- Add an LLM to the design: the LLM system design interview guide applies this framework to AI features.
