The shape of a system design answer
Every good system design conversation — in interviews and in real engineering — follows the same five moves, in order: clarify what to build → put numbers on it → define the operations → draw the architecture → stress-test it. Skipping ahead is the classic mistake; drawing boxes before knowing the requirements means designing a system for a problem you invented.
You already have every move: requirements and APIs (lesson 2), estimation (the 4-step method), the building blocks (load balancers, caches, and friends), and reading diagrams (lesson 1). This lesson is about the ORDER, and about letting each move feed the next.
The five moves
Each move produces exactly what the next one needs.
| Move | You ask / decide | Feeds the next move |
|---|---|---|
| Requirements | What must it DO? How well? What can we skip? | The list every later decision traces back to |
| Estimation | How many users, requests/sec, GB? | Which parts need scaling machinery at all |
| API & data | What operations? What records? | What the boxes in the diagram must accomplish |
| Architecture | Which components, connected how? | The design to defend |
| Deep dive | What breaks first? What if X dies? | The fixes — and proof you understand your own design |
A full run in three minutes: SliceNow, final form
Requirements: customers browse menus, order, and track delivery; orders must never be lost; menus must load instantly; survive dinner rush. Estimation: 10M orders/month ≈ 4/sec (peak ~25/sec — easy); menu reads ~400/sec and spiky (the real load); receipts and emails are slow side work.
API: GET /menu, POST /orders, GET /orders/{id} — one endpoint per requirement. Architecture, derived not guessed: the read spike says cache; more-than-one-server says load balancer; "never lose an order" says the database is the write path's destination; slow side work says queue + worker.
Deep dive: "What if the cache dies?" — all 400 reads/sec fall through to a database that handles 1,000/sec... tight but survivable; re-warm the cache and watch it. "Queue backs up?" — orders still get accepted and stored; emails arrive late. Notice every answer follows the same shape: which component → what breaks → the fix and its cost.
Order writes (peak)
~25/sec — easy
Menu reads (peak)
~400/sec — cache it
Emails/receipts
slow → queue it
Quick check
An interviewer says "design a ride-sharing app" and you immediately start drawing a load balancer and database. What did you skip, and why does it matter?
Match them up
Match each pain to the piece that cures it — this is the whole course in one exercise.
0/5 matched — tap a term on the left.
Build it yourself
The graduation build. Assemble the full design: traffic spread across app servers, hot reads cached, orders stored safely, and slow email work deferred so customers never wait on it. Two palette pieces do NOT belong — leave them off.
Surviving the deep dive
The last interview move is the stress test: "what breaks first at 10× traffic?", "what if the cache dies?". These questions feel scary and are actually the most formulaic part of the whole hour. Every strong answer has three beats: name the specific component → say concretely what goes wrong there → give the fix and what the fix costs.
Compare: "I'd add redundancy" (says nothing) with "At 10×, the database is first to fall — 4,000 menu reads/sec against a 1,000/sec ceiling if the cache underperforms. I'd verify the cache hit rate first, then add read replicas; that buys read capacity but adds replication lag I have to tolerate." Component, breakage, fix, cost. Practice that rhythm and the deep dive becomes your strongest section.
Tip — Narrate the WHY
In the real interview, say the pain out loud before naming the cure: "reads dwarf writes, so I'll cache the menu" beats "I'll add Redis." Interviewers are not checking whether you know components exist — they are checking whether you know why.
Graduate: take a real interview
You now have all five moves. The simulator will run you through requirements, estimation, API design, the architecture canvas, and deep-dive questions — with an AI interviewer who answers your clarifying questions and probes your design. Exactly the loop you just learned.