Introduction
A system design interview asks you to make useful decisions while the problem is still incomplete.
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.
The mechanism at a glance
Figure — User action → Explicit contract (clarify); Explicit contract → Stored truth (model); Stored truth → First design (trace); First design → Pressure test (challenge); Pressure test → Revised decision (adapt)
The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.
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.
Figure — 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.