Learn Functional vs. Non-Functional Requirements, Availability, Latency, Assumptions, and Scope Using a Real-World E-Commerce Order Tracking Example.
Tagline: The Best Architects Don't Start With Solutions. They Start With the Right Questions.
Stop Drawing Boxes: The Questions to Ask First in a System Design Interview
"Show customers the status of their order." It sounds clear. It is not. The first five minutes of questions can change the whole design.
The problem at Varastra
Varastra is an online store for Indian ethnic wear. It sells sarees, kurtas and lehengas. Nina is in a practice interview with Ben.
Ben gives the task:
Design the order tracking page.
Nina starts to draw. Ben stops her. "What did I just ask you to build?"
She thinks. Does the page show only the current status, or the whole history? Can a customer cancel from it? Does it show a live map? Can any user open any order? She had assumed answers to all four. Each wrong guess would have changed her design.
The diagram at a glance
The diagram is a requirements board with four areas.
- Functional. What the system does. Example: a customer views the status of an order.
- Non-functional. How well it does it. Example: a new status shows within one minute.
- Assumptions. Things you decide and say aloud. Example: customers only, not staff.
- Out of scope. What you will not build. Example: returns and refunds.
Fill the board by asking questions. Write the answers where everyone can see them.
The board for Varastra
| What it does | How well it works | Out of scope |
|---|---|---|
| View current status | New status shows within 1 minute | Live map |
| View expected delivery date | Status is never lost | Refunds |
| View status history | Only the order owner can see it | Cancelling orders |
All of these answers are made up for the story.
How one answer saves work
Pause and predict. The board says a new status may take up to one minute to show. Does Varastra need a live push connection? Decide, then read on.
Look at "a new status may take up to one minute to show."
This one line means Varastra does not need a live push connection. A live push connection stays open and sends each update the moment it happens. It is harder to build and run. The page can simply fetch the status when the customer opens it.
One question saved a lot of design work. That is the point of this step.
Good questions to ask
- Who uses it? Customers, staff, other systems?
- What are the two or three main actions?
- How fresh must the data be?
- What happens if it is wrong or late?
- Which countries or devices matter?
- What is out of scope?
Try it. Take the cart page. Write one thing it does, one thing about how well it works, and one thing that is out of scope. Here is an example. It does: add and remove items. How well: the cart is still there after the app closes. Out of scope: checkout and payment.
When the interviewer says "you decide"
Choose a sensible answer and say it clearly. For example: "I will assume status can be a minute old. Tell me if that is wrong." This shows judgment. It is advice, not a rule from any company.
Takeaways
- Ask before you draw. One answer can remove a lot of design work.
- Split requirements into what it does, how well it works, and what is out of scope.
- Write the answers on the board so everyone can see your assumptions.