Learn System Design Interview Preparation Using a Real E-Commerce Example — Varastra. Master Requirements, Capacity Estimation, APIs, Architecture, Deep Dives, Trade-Offs, and System Reliability.
Tagline: Don't Just Draw Boxes. Learn to Think Like a System Architect.
A system design interview has no single right answer. That is exactly why you need a plan. Seven steps, in a fixed order, tell you what to do next, even when your mind goes blank.
The problem at Varastra
Varastra is an online store for Indian ethnic wear. It sells sarees, kurtas and lehengas. Rina is a new engineer there, and she is preparing for a system design interview.
Jonas, a senior engineer, agrees to run a practice round. He gives the task:
Design the order tracking page for Varastra.
Rina walks to the whiteboard. In ten seconds she draws a cache. Then a queue. Then a second database.
Jonas points at the queue and asks:
Why is this here?
Rina has no answer. She had drawn the box because big systems usually have one. Her board was full, but she could not defend a single box.
The diagram at a glance
Pause and predict. You have 45 minutes. Which of the seven steps should get the most time? Make a guess, then look at the table.
The diagram shows seven steps in a row. Under each step is a number of minutes. Read it from left to right.
| # | Step | Suggested minutes |
|---|---|---|
| 1 | Requirements | 5 |
| 2 | Approximate | 4 |
| 3 | Core API and data | 5 |
| 4 | High-level design | 8 |
| 5 | Deep dives | 12 |
| 6 | Trade-offs | 8 |
| 7 | Wrap up | 3 |
The minutes add up to 45. This split is a practice suggestion, not a rule. No source says any company uses it. A 35-minute or 60-minute round needs a different split. If the interviewer jumps ahead, follow them.
Did you pick step 5? In this suggested split, deep dives get 12 minutes. That is the largest share.
The seven steps, with Varastra
1. Requirements. Ask what the system must do, how well it must do it, and what is out of scope. For Varastra: customers see order status and history. A new status may take one minute to show. There is no live map. These answers are made up for the story.
2. Approximate. Estimate the size. How many orders? How many page views a second? How much data? The numbers tell you how big the system must be.
3. Core API and data. Write the two or three main calls. For Varastra: "get order status" and "post new status." Say what data is stored.
4. High-level design. Draw the main parts and how data moves. For Varastra: a customer app, a load balancer, a tracking service and a database. Four or five boxes are enough.
5. Deep dives. Pick the hard parts. What if a delivery partner sends the same update twice?
6. Trade-offs. Every choice gives something up. Say what can fail and what you gave up.
7. Wrap up. Say how you would watch the system and how it would grow. Then summarize in a few sentences.
Try it. Take a new task: "Design the cart page for Varastra." Before you draw anything, write three requirement questions. Here are examples. Can a guest add items? How long does an item stay in the cart? Is stock held for the customer? Your questions may differ. The point is to ask first.
Why the order matters
Each step feeds the next one.
- Requirements tell you which numbers to estimate.
- The numbers tell you which boxes to draw.
- The boxes show you where the hard parts are.
- The hard parts give you the trade-offs to discuss.
Rina drew first. So she had no reason for any box. When she restarted, she asked questions first. Her board ended with five boxes, and she could defend every one.
Takeaways
- Follow the same seven steps every time: requirements, approximate, core API and data, high-level design, deep dives, trade-offs, wrap up.
- Each step feeds the next. Questions give numbers, numbers give boxes, boxes show the hard parts.
- Use the time split as a guide. Follow the interviewer if they jump ahead.