How do you design the whole product in a system design interview?

In this article

1. Before you start
2. Why interviewers ask this
3. Designing the whole product from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page belongs to the distributed systems interview learning path, which explains how the whole round works.

Why interviewers ask this

A product prompt tests whether you can create structure from a vague request, which is most of real design work. Candidates report prompts such as an online store with search, cart and shipment, a code-hosting product, a calendar, a personal finance tool that syncs card spending, or a webhook system. These are reports from candidates, not confirmed company practice. System design is a required part of the technical interview process at many tech companies, as the system design primer notes.

A weak answer starts drawing databases and caches before anyone has said what the product does. A strong answer fixes the scope, names the main things the system stores, lists the requests users make, and only then draws boxes. A Staff-level answer also says which numbers change the design and which do not.

"Design the whole product" is a descriptive label for these full-product rounds, not a formal term. The order below follows a published system design delivery framework, read on 2026-10-26.

Designing the whole product from first principles

Functional requirement

A functional requirement is a statement of the form "users should be able to ..." that names one thing the product must let a user do. Each one becomes a feature, and later an endpoint, of the design. A short, prioritised list of them defines what you will build in the interview and what you will leave out.

Non-functional requirement

A non-functional requirement is a quality the system must have, best stated with a number, such as how fast a search must answer or how long data must be kept, that shows which part of the design needs the most care. A target like "search answers in under half a second" is more useful than "search is fast", because it names the part and gives a number.

Core entity

A core entity is a noun that the product stores and that the API sends and receives, such as a user, a product or an order. The first list of them is a draft that you refine during the high-level design. It holds names and relationships only, not every field of every table.

In plain words

Think of building a house. You first agree what the family needs. Then you list the rooms. Then you mark the doors, and only after that do you draw the floor plan. Plumbing detail comes last.

A product design works the same way. Requirements are the brief. Entities are the rooms. Endpoints are the doors. The high-level design is the floor plan. Deep dives are the plumbing.

The analogy breaks in one place. A house is built once, but a software product keeps changing, so you also say which parts will be easy to change later.

In one precise sentence: a whole-product design is a chain in which each step takes the output of the step before it and adds one kind of detail.

Step 1: Cut the requirements to three features and a few measurable qualities

Requirements are the statements that fix what the system must do and how well. The framework says a long list hurts more than it helps, and that many large employers judge your ability to focus on what matters. It suggests about three core features and three to five non-functional requirements.

Input: the vague prompt. Output: a short list of functional requirements plus quantified qualities. Ask the interviewer to confirm the list.

For an online store, three features might be: search products, cart and checkout (add an item, place an order), and track a shipment. A quantified quality is "search answers in under half a second", the style of target the framework recommends. Its checklist of qualities includes the trade-off between consistency and availability, scalability, latency, durability, security and fault tolerance. You now have a scope. The next step names what the system holds.

Step 2: List the core entities as a first draft

Core entities are the nouns behind your requirements. For the store they are user, product, cart, order and shipment. Write names only, and note how they connect: a user has one cart, and an order has many products.

Input: the requirements. Output: five or so noun names with their links.

The framework warns against listing the entire data model now, because you do not know what you do not know yet. Fields such as price or address can wait. They appear when an endpoint needs them.

This step takes about two minutes in the framework's time budget. Spending ten minutes on a table design here is a common way to run out of time before the architecture exists. You now have the nouns. The next step names the verbs.

Step 3: Turn each requirement into an API endpoint

The API is the list of requests a client may make, and it is your checklist for the rest of the design. The framework notes that it often maps directly to the functional requirements, though not always.

Input: requirements and entities. Output: one endpoint group per requirement, with method, path and the entities it carries.

For the store, one endpoint group per feature: search products; add an item to a cart and place an order; and read a shipment's status. The framework advises defaulting to REST unless you have a specific reason not to, and taking the current user from the authentication token rather than from the request body. It suggests GraphQL when clients are diverse and remote procedure calls (RPC) for internal, performance-critical calls.

REST itself comes from Fielding's doctoral dissertation (2000), which defines it as an architectural style built on resources.

A quick test: if a requirement has no endpoint, or an endpoint has no requirement, one of them is wrong. You now have the verbs. The next step connects them to machines.

Step 4: Build the high-level design by walking the endpoints

A high-level design is a drawing of the services, stores and queues that together serve every endpoint. The framework says you can go through your endpoints one by one and build the design sequentially to satisfy each one.

Input: the endpoint list. Output: a diagram where every endpoint's path from client to storage is visible.

For "search products", draw a client, a service and a search index. For "place an order", add an orders database. For "read shipment status", read from that database or from a shipment service. Keep the first drawing simple. The framework notes that candidates often add complexity too early and never reach a complete solution.

Refine the entity list as you go; a missing entity usually shows up here. You now have a complete but plain design. The last step decides where to spend your remaining time.

Step 5: Pick the deep dives where the requirements push hardest

A deep dive is a focused look at one part of the design where a requirement is hard to meet. A strong answer picks one or two, says why, and works them through.

Input: the high-level design and the quantified requirements. Output: a short, reasoned improvement to the weakest point.

Pick where your own numbers or targets bite. If search must answer in under half a second, discuss the index and caching. If orders must never be lost, discuss durability and what happens when a payment step fails; the payment system page goes further. If one endpoint is called very often, discuss rate limiting at the gateway or a distributed cache.

Say out loud what you chose not to cover. That shows judgement.

1 · Requirements2 · Entities3 · API4 · High-level design5 · Deep divesReplay

Step-by-step description

1. Cut to three features and quantified qualities.
2. List the nouns as a first draft.
3. One endpoint per requirement.
4. Walk the endpoints one by one.
5. Spend time where targets bite.

• Requirements come first, then core entities, then API endpoints.
• The high-level design comes next, then the deep dives.

Worked example

Take the online store and ask one question: do the numbers change the design? Every input below is an assumption, labelled illustrative. The method is the one on the back-of-the-envelope estimation page.

Assume 2,000,000 daily active users (DAU), each doing five searches, fifteen product views and two cart changes a day, and 2% of users placing an order. That is 10,000,000 searches, 30,000,000 product views, 4,000,000 cart changes and 40,000 orders a day.¹ A day has 86,400 seconds, and a peak of three times the average is also an assumption.¹

The read/write ratio is the number of reads divided by the number of writes over the same period.¹ Here it is about ten, so the design effort belongs on reading: a search index and a cache for popular product pages. Orders add 80 megabytes a day, and a year of them is 29.2 gigabytes, so one well-run primary database holds them and sharding orders is not needed yet.¹

Text description of the diagram

• Peak product views reach 1,041.67 queries per second and peak orders only 1.39.
• Reads dominate writes, so the design effort goes to reading.

Peak product views reach 1,041.67 queries per second and peak orders only 1.39.¹ That conclusion changed the design, which is the framework's test: estimate only where the number changes a decision. It notes that many candidates compute storage, DAU and QPS and then conclude "it is a lot" without using the result.

Trade-offs and edge cases

Case 1: estimation placement. Reported practice differs on when to estimate. The framework says to do it only when the result changes the design, so a candidate who opens with capacity math may spend minutes on a number that decides nothing. If the interviewer asks for estimates early, give them.

Case 2: API style. REST is the default, but a specific reason justifies another style. GraphQL typically costs more because you must define a schema and write resolver code for each field, and because requests go through one endpoint, ordinary web caching of responses is harder. Remote procedure calls typically need generated client code and are not supported by browsers directly, so they fit internal services better than public clients.

Text description of the diagram

• REST is the default unless there is a specific reason not to.
• GraphQL suits diverse clients and remote procedure calls suit internal performance-critical calls.

Case 3: time. The framework budgets about five minutes for requirements, two for entities, five for the API, an optional five for data flow and ten to fifteen for the high-level design. That is 22 to 32 minutes before deep dives.¹ If the interviewer talks less than expected, you have room; if they interrupt, drop the optional data-flow step first.

Case 4: product type. A webhook prompt has few entities but a hard delivery problem, so the deep dive is webhook delivery and payloads. A calendar or finance-sync prompt pushes weight onto the data model, so the database questions matter more.

How to answer it in an interview

The spoken structure: confirm scope, name entities, list endpoints, draw the design endpoint by endpoint, then deep dive and state what you skipped.

Common mistakes

• "I will list every feature the store could have." (wrong) A long list stops you reaching a complete design. (right) "I will pick the top three features and confirm them."
• "First I compute storage, DAU and QPS." (wrong) The numbers may decide nothing. (right) "I will estimate only if the result changes a design choice."
• "Let me design all the tables." (wrong) You do not yet know the fields. (right) "I will list entity names now and add fields when an endpoint needs them."
• "I will use the newest technology for the API." (wrong) Exotic choices early add risk. (right) "I will use REST unless there is a specific reason not to."
• "Let me deep dive into search now." (wrong) The high-level design does not yet cover every endpoint, so you may never finish it. (right) "I will first make sure the design covers every endpoint, then pick one deep dive."

Follow-up questions

How would you scale an API to meet market demands?

Start from the quantified requirements and find which endpoints carry the load; the read/write ratio shows whether caching or write capacity matters most. Then protect the service with limits at the gateway, as in the rate limiter design, and cover the general round in the backend interview questions.

How do you design an e-commerce platform with search, cart and shipment?

Use the five steps above: three features (search, cart and checkout, shipment tracking), five entities, endpoints for each feature, a design built from those endpoints, and deep dives on search and order durability.

How do you design a GitHub-like system?

Pick three features, such as storing repositories, pushing changes and viewing them, and name entities like user, repository and change. Then derive endpoints and draw the design from them; the deep dive depends on which requirement is hardest.

How do you design a personal finance platform that syncs credit card spending?

The entities are user, linked account and transaction, and the hard part is a reliable sync from several outside sources. Treat money movement and duplicate handling as the deep dive, with ideas from the payment system page.

How do you design a system around a webhook and its payload?

Define the event entity and its payload fields, then the endpoint that receives it, and deep dive on retries and verification. The webhook page explains the mechanism.

What changes if traffic is ten times higher, for example on a sale day?

In the illustrative store, peak product views go from about 1,042 to about 10,417 queries per second, while orders reach only about 14 per second.¹ Caching and read replicas become the priority, and order write capacity still is not the problem.

Sources

1. System Design Interview Delivery Framework — Hello Interview (accessed 2026-10-26; page undated), 26 Oct 2026
2. Architectural Styles and the Design of Network-based Software Architectures (Chapter 5, REST) — University of California, Irvine (Fielding, doctoral dissertation), 1 Jan 2000
3. system-design-primer (README) — GitHub, donnemartin (accessed 2026-10-26; page undated), 26 Oct 2026