Introduction
A system design interview asks you to make useful decisions while the problem is still incomplete.
What, why, when and how
What is it?
A system design interview is a conversation about turning incomplete product requirements into a defensible architecture. Your visible reasoning is the evidence the interviewer can examine.
Why is it needed?
A list of technologies cannot show that a user action works or that a business rule survives a race. A concrete request, state change and failure trace make those claims testable.
When should I use it?
Use this approach at the start of a product or infrastructure design prompt, after clarifying whether the discussion is high-level design, low-level design or an ML system.
When should I choose something else?
Do not apply one memorized architecture to every prompt. If the interview asks for class design or model evaluation, agree on that boundary and adapt the deliverables.
How do I use it?
Ask which user actions matter, propose explicit assumptions, define success and one invariant, then explain a complete path before choosing a deep dive.
Can you show a concrete example?
For an export: authenticate tenant t1, commit job j7 and its publication record, return durable acceptance, produce immutable output v8, and authorize its download. Ask what happens if the worker crashes between uploading v8 and publishing it.
Read the diagram
Scope: tenant t1 requests an export; Acceptance: commit job j7 and return its ID; Completion: publish output v8; authorize download
Follow the detailed diagrams below to trace the additional state changes and failure cases behind these answers.
A system design interview asks you to make useful decisions while the problem is still incomplete. The interviewer cannot inspect a system you have already built; they can only inspect the reasoning you make visible. A good answer connects a user action to a contract, a contract to stored state, and that state to a design that survives realistic failures. You do not need to guess a company's private architecture. Throughout this course, product names describe interview exercises, not claims about those companies' implementations.
Learning goals
What a design interview evaluates; product versus infrastructure prompts; turning ambiguity into explicit assumptions; communicating incomplete information; adapting depth to seniority.
Make interview expectations observable
A product interview asks for user behavior, such as creating and downloading an export. An infrastructure interview may ask for a scheduler or cache interface. LLD focuses on classes/collaboration; ML design can include data, features, training and evaluation. Clarify the expected boundary instead of treating all of these as the same exercise.
Read the diagram
Component list: queue + Redis + database; Working path: t1 -> job j7 -> immutable file v8; Changed requirement: minutes -> five seconds; Decision: bound size, precompute, stream or change promise
“Use a queue, Redis and a database” does not show a working export. “Authenticate t1, atomically create job j7 and its outbox, return j7, generate immutable file v8, and authorize its download” does. A reviewer can now ask what happens when the worker crashes after upload. Explain the persisted identities and repair path before adding more technologies.
Assess navigation through clarified assumptions, design through a complete path, technical depth through one defended bottleneck, and collaboration through responding to a changed requirement. At senior level, ownership and failure boundaries matter more than an elaborate catalog of components. An interviewer's exact rubric varies; use these as observable learning criteria, not a guaranteed hiring score.
Show answer and explanation
Answer: Changing the goal from minutes to five seconds challenges the export workload and promise. Bound file size, precompute, stream or negotiate the requirement; merely adding replicas does not make unbounded compute meet five seconds.
The mechanism at a glance
Read the diagram
Request an export: who may read it? → Accept durably: return one job ID → Worker publishes one file version → New requirement: finish in five seconds → Revisit size limits and precomputation
The numbered sketch follows one export conversation. Durable acceptance and file readiness are different promises. The last two steps change the requirement and revisit the design.
Step-by-step reasoning
1. Start a conversation, not a component list
For “design document export,” first ask who requests exports, how large a document can be, and whether waiting minutes is acceptable. If the interviewer leaves this open, choose a concrete assumption and say it aloud. “I will return a job ID immediately and make the file available later” creates a design boundary. “I will use Kafka and Redis” does not explain the product behavior.
2. Separate requirements from preferences
A user must not download another tenant’s export is a requirement. PostgreSQL is a possible implementation choice. Keep these on different parts of the page. Identify an invariant, such as one visible output per export version, and an objective, such as 95% of small exports finishing within a minute. An objective can be measured; an invariant needs a mechanism that prevents violations.
3. Build one complete path
Trace a single export from authenticated request through durable job creation, worker execution, object upload, and authorized download. Name what each response promises. Acceptance is not completion. Draw the simplest path first so the interviewer can challenge it. Add scale only when a measured or assumed pressure exposes a bottleneck.
4. Adapt to new evidence
If exports suddenly require interactive latency, acknowledge that the old workflow no longer satisfies the goal. Explore precomputation, size limits, streaming, or a changed product promise. Do not defend your first diagram as if changing it were failure. Senior-level depth often comes from migration, operational ownership, tenant isolation, and failure recovery, rather than extra boxes.
Contracts and state
The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.
Decision log
Action: request an export
Invariant: output belongs to the requesting tenant
Promise: 202 means durable acceptance, not completion
Assumption: most exports are smaller than 100 MB
Risk: very large exports consume the worker pool
Next measurement: queue age by size classWorked example
Compare two openings. Candidate A lists six technologies and asks whether the interviewer likes them. Candidate B asks whether an export must be synchronous, proposes a one-minute completion target for small jobs, and distinguishes acceptance from download readiness. Candidate B gives the interviewer a useful surface for correction. If the target changes to five seconds, the conversation immediately turns to export size and precomputed data rather than swapping unrelated databases.
Failure walkthrough
An incomplete answer is not automatically a weak answer. Hiding uncertainty is worse. When time runs short, finish the critical path, name the unresolved failure, and say how you would investigate it. For example: “The current design can duplicate execution after a lease expiry; the next step is to fence result publication with an attempt number.” This is more precise than declaring the system fault tolerant.
Read the diagram
Prompt: export documents → Assume async completion → Trace one durable job → Interviewer tightens latency → Revisit size and precomputation
Decisions and trade-offs
| Move | Useful evidence | Avoid |
|---|---|---|
| Clarify | A user action and success condition | A long questionnaire with no decision |
| Estimate | A number that changes capacity | Arithmetic disconnected from the design |
| Deep dive | An invariant under a concrete race | Listing every available service |
Check your understanding
Give a two-minute opening for a messaging service. Explain what changes if the user must see a message on all devices before send succeeds.
Show answer and explanation
Answer: Ask whether send acknowledges server persistence or every recipient device. The second contract couples availability and latency to offline devices. A more usable contract often separates accepted, delivered, and read states; justify it with the interviewer rather than silently changing the requirement.
Transfer to a new scenario
Compare two openings for the same document-export prompt and explain why one gives the interviewer clearer decisions.
Explain a design choice when the interviewer changes the latency target.
Continue the connection
Study Delivery Framework and explain which guarantee from this lesson carries into that topic.
Choose your learning depth
Start with vocabulary and one concrete operation. Then practice the scaling trigger, concurrency boundary and failure repair. For senior/staff preparation, justify the alternative, operational ownership and a staged rollout with a rollback condition. Follow the Interview Playbook for clarification questions, a timed answer sequence and examples across messaging, video and expense sharing. These are learning tracks, not a universal hiring rubric.
Rehearse the first ninety seconds
Try this opening aloud before reading the explanation: an administrator requests a student-data export, most files are small, and some take several minutes. Which two questions change your baseline?
Ask what a successful submission promises and who may download the result. A useful opening is: “I will assume submission acknowledges a durable job, while download becomes available later. The file belongs to the requesting tenant. Is that the intended contract?” These assumptions establish the asynchronous and authorization boundaries without requiring a storage product first.
Now the interviewer says the browser may close immediately after submission. Predict the effect: the accepted job must survive independently of the browser connection. Next, the worker uploads bytes but crashes before recording completion. Explain who owns publication of the result and how the retry discovers or replaces the unpublished output. Do not claim that an uploaded object alone proves completion.
Show answer and explanation
Answer: Keep the accepted job and its identity durable. Publish an immutable output reference only under the current job attempt's ownership rule. A status request checks the requesting tenant and returns accepted, running, completed or failed according to recorded state. Orphan cleanup follows a retention policy; it must not delete the current published generation. Other implementations are possible if they enforce the same stated contract.
Your practice evidence is a spoken scope statement, one complete path, and an explained crash boundary. A more elaborate drawing is useful only when it clarifies one of those claims.