Interview guide
A system design interview framework you can actually say out loud
Interviewers aren't grading whether you build Google in 45 minutes. They're grading whether you ask the right questions, keep the design correct when things fail, and explain your tradeoffs.
Updated October 31, 2026
- Clarify scale, latency and correctness before drawing anything.
- Name one rule the design must never break.
- Start simple. Add scaling only when the numbers require it.
- Spend real time on failures: that's where senior candidates stand out.
The steps
- 1Restate the problem in one sentence and say what's out of scope.
- 2Ask five questions: who the users are, the main actions, scale, speed and correctness needs.
- 3Requirements: 4–6 functional and 4–6 non-functional (availability, latency, durability, cost).
- 4The main rule: for a ticketing system, “a seat is sold at most once”. Every later choice protects it.
- 5Core data and APIs: a few objects and 3–5 endpoints, each with its retry behavior. For example, “POST /orders takes an idempotency key so a retried request doesn't create two orders”.
- 6Architecture: one left-to-right flow, such as Client → API → DB → Queue → Workers.
- 7The hardest part: pick one (duplicate work, hot keys, ordering) and go deep.
- 8Failures: for each, give a simple example and how you handle it.
- 9Measurements and tradeoffs: what you'd watch and the 2–3 choices you made.
Failures worth mentioning
| Failure | Simple example | How to handle it |
|---|---|---|
| Duplicate request | User double-clicks “pay” | Idempotency key stored with the result |
| Reply lost after success | Payment succeeded, response timed out | Client retries with the same key and gets the stored result |
| Worker dies halfway | Job claimed, then the machine restarts | Lease with a timeout, so another worker picks it up |
| Out-of-order messages | Old location update arrives late | Version numbers; ignore older updates |
| Hot key | Celebrity post gets all the traffic | Cache it and split counters |
| Retry storm | Dependency recovers and gets flooded | Backoff with jitter and a cap on retries |
Say it simply
Plain words beat jargon. Say “compare what should have happened with what did, and fix it” instead of “reconciliation”, and “slow down or reject new work when overloaded” instead of “backpressure”. Interviewers trust candidates who explain clearly.
Walk into your next interview prepared
Build an assistant from your resume and the job description, then get speakable answers in real time. Pay by the hour, no subscription.
Keep reading
Turn any system design question into a compact, speakable framework: requirements, APIs, architecture, failures, measurements and tradeoffs, in plain English.
What to say in a live coding interview, step by step: clarify, restate, brute force, optimize, code, test and complexity, with a Two Sum example.
RightInterview vs Final Round AI compared: pay-by-the-hour vs subscription, editable assistants from your documents, and live human support.