A system design interview presents an open-ended problem and asks for a solution that can be explained, discussed, and refined. The diagram makes the data’s path traceable; the conversation makes assumptions, decisions, and tradeoffs visible.
Hello Interview’s Delivery Framework organizes that delivery into five main stages: requirements, entities, APIs, high-level design, and deep dives. The sequence helps maintain a coherent conversation; it adapts to the problem, available time, and interviewer feedback.
--- config: look: handDrawn --- flowchart TD requirements["1 · Requirements<br/>Functions and priorities"] --> entities["2 · Entities<br/>Concepts and relationships"] entities --> api["3 · APIs<br/>Operations and contracts"] api --> baseline["4 · High-level design<br/>Complete basic flow"] baseline --> deep["5 · Deep dives<br/>Challenges and tradeoffs"] deep -.->|"Revisit assumptions"| requirements
Functional and non-functional requirements
The first stage defines what the system must do. For a ticketing service, the core operations might be browsing events, holding seats, and confirming a purchase. The exercise’s scope should be agreed on before designing additional features.
Non-functional requirements define priorities and constraints: capacity, latency, availability, durability, consistency, and operational limits. They need to be made concrete for operations and data. Search may accept delayed information, while allocating a seat must protect inventory; the ticketing case shows why those priorities are separated.
Ask which priorities matter most and record assumptions when the prompt does not establish them. “Scaling” needs a workload and a target; “being consistent” needs to specify which state and observations must agree. A list of adjectives does not determine an architecture.
Estimates are made when they change a decision. File size and retention can justify where to store content; bursts and processing capacity can reveal a backlog. Numbers need units, assumptions, and headroom. If an estimate does not affect the solution, time spent on it may displace a more relevant challenge.
Entities and relationships
Entities capture the concepts needed for the operations: user, event, seat, hold, and order, for example. Their relationships, owners, and states are identified with enough detail to reason about the flow.
An entity does not require creating a table for every name. It may become a row, document, aggregate, or reference, depending on access patterns and invariants. The data model is shaped by those needs; the entire physical schema does not need to be settled at this stage.
Useful questions include what identifies a resource, who can act on it, and which changes must be coordinated. A hold has an owner and a validity period; an order needs a status the client can query after losing a response.
The model is refined during the interview. An API may reveal a missing operation entity, and a deep dive may require a version or event record. Revisiting the model for a concrete reason is part of the process.
APIs and contracts
APIs express the operations consumers will use. An interface may include reading an event, requesting a hold, and retrieving a purchase’s status. Each operation defines inputs, results, permissions, and relevant errors.
REST over HTTP is often a practical starting point, but the contract may justify GraphQL, RPC, or another interface. Explain why it fits the consumers and problem. Choosing gRPC does not automatically ensure lower latency or eliminate network and coordination costs.
Identity and authorization depend on the operation. Browsing a public catalog may not require a session; modifying a resource or holding inventory requires appropriate permissions. Client-supplied identifiers select targets and must be authorized, without making the body a trusted source of identity.
It is also useful to clarify what a successful response means. Accepting asynchronous work does not imply completion, and a timeout leaves an uncertain outcome. The contract should allow status checks or retries with an appropriate idempotency strategy, without promising that every external operation executes exactly once.
High-level design: complete the basic flow
The fourth stage builds a solution covering the agreed requirements end to end. A request enters, is validated, queries or changes state, and produces a result. That complete path should be explainable first.
Components are chosen by their function and limits. The table includes illustrative examples whose specific contracts need evaluation:
| Component | Possible responsibility | Decision worth explaining |
|---|---|---|
| Application servers | Execute rules and serve operations. | Local state, concurrency, and scaling. |
| Database (PostgreSQL, DynamoDB) | Preserve facts and protect changes. | Access patterns, transactions, and data authority. |
| Cache (Redis) | Avoid repeated work for certain accesses. | Freshness, invalidation, and failure behavior. |
| Queue or log (Kafka) | Separate processing and retain events under its contract. | Capacity, delivery, ordering, retention, and recovery. |
| Load balancer | Distribute traffic among instances. | Health, affinity, and destination limits. |
| Object storage (S3) | Store and retrieve files as objects. | Permissions, versions, and upload finalization. |
| CDN | Serve content close to the consumer. | Caching, access, and content updates. |
Not every component is needed in every exercise. Each box should have a verifiable role in the flow. Introducing multiple services or distributed storage without a need can add failures and coordination before solving the basic case.
Hello Interview also includes an optional data flow. Walking through an operation step by step can clarify transformations or processing stages. It is used when it helps the problem, without becoming a mandatory sixth stage for every interview.
Deep dives guided by challenges
Once a complete basic solution exists, attention turns to the points that challenge it. Priorities come from requirements and feedback: a hot key, traffic spikes, concurrent writes, payment recovery, or geographically distributed reads can call for different discussions.
A deep dive should show the problem, an alternative, and its cost. Adding a cache requires deciding which delay is acceptable and how to recover from an outage; the caching strategy affects the whole system. Distributing data requires justifying keys and cross-shard operations, rather than merely drawing several databases.
Under heavy traffic, the rate limiter opens a discussion of admission and fairness. With asynchronous work, queues raise questions about backlog, duplicates, and idempotent effects. The mechanism that solves the case’s challenge is explored in depth, with its conditional guarantees.
An operation is also followed through a failure: what was confirmed, which result is uncertain, what can be repeated, and how recovery is observed. If a new constraint changes the design, requirements are revisited and the flow is adjusted. The goal is to preserve the relationship between decisions and priorities.
Four areas of preparation
Hello Interview’s preparation guide organizes its path into Foundation and Practice. The following grouping into four areas is an editorial synthesis for organizing that work.
1. Understand the interview
Learn what kind of interview will be held, its duration, and the expected depth. The solution is built collaboratively: clarifying ambiguity, asking about priorities, and explaining a decision keeps time focused on the agreed problem. Different requirements can support multiple valid solutions.
Communication also takes practice. A readable diagram identifies components, data, and meaningful arrows. A useful explanation connects each choice to a requirement and identifies what remains an assumption. If a number or guarantee is missing, the uncertainty is stated and its effect on the design is explained.
2. Refresh fundamentals
For databases, access patterns, indexes, transactions, and replication matter. For networks, the request’s path, connections, latency, and failures matter. OSI and CAP provide vocabulary when applied to concrete decisions; CAP helps discuss which operations can continue during a partition and with what consistency.
Vertical scaling adds resources to an instance; horizontal scaling distributes work or data across several instances and requires resolving their coordination. Consistent hashing can help place keys and reduce redistribution when nodes change, without guaranteeing uniform load. These concepts are studied through the bottlenecks they address and the costs they introduce.
3. Learn components
The high-level design table offers a starting point: servers, PostgreSQL or DynamoDB, Redis, Kafka, load balancers, S3, and CDNs. For each component, explain its responsibility, access patterns, state, and failure behavior. Product knowledge helps when it supports those decisions; guarantees depend on the contract and how the product is used.
4. Attempt problems before reading solutions
A useful practice cycle is choosing a question, reading its requirements, attempting an independent solution, comparing it with a reference walkthrough, and doing mock interviews to receive feedback.
An illustrative target for this editorial practice plan is ten varied problems, with the number adjusted to available time and areas that need more work.
Exercises inspired by Bitly, Dropbox, Ticketmaster, or Uber cover different problems: shortening URLs, handling files, selling inventory, and coordinating locations or assignments. They are prompts for practicing decisions, rather than claims about those companies’ internal architectures. The selection is adapted to areas that need more practice.
Before opening a solution, a proposal is drawn and assumptions and questions are recorded. When comparing, explain which decision would change and why. A reference solution helps uncover alternatives and gaps in reasoning; copying its components does not demonstrate that they can be justified in another case.
The review can check whether the flow covers requirements, state authority is clear, access patterns support queries, and failures have recovery paths. Mock interviews add practice in communication, time management, and adapting to feedback.
The System Design path offers mechanisms and cases for that practice. The framework organizes delivery; understanding guarantees and justifying tradeoffs allows it to be used thoughtfully.