Most system-design interviews — and plenty of real design meetings — start with someone reaching for a whiteboard marker and drawing a load balancer. That is the wrong first move. The right first move is asking questions, because the answers decide most of the architecture for you.

1. What does "success" look like in numbers?

Requests per second, data volume, read-to-write ratio, acceptable latency. A system that serves ten requests a minute and one that serves ten thousand a second are different animals, even when they share a name.

2. Which part must never be wrong?

Payments and inventory need strong consistency. A like counter does not. Naming the one or two places where correctness is non-negotiable lets you relax everywhere else.

3. What happens when it fails?

Every component will fail eventually. Decide up front what the user sees, what gets retried and what gets dropped.

A quick failure table

  • Database down — serve cached reads, queue writes, show a banner.
  • Third-party API down — degrade the feature, not the whole page.
  • Queue backed up — shed load or slow producers before it cascades.

4. How will it grow?

Design for ten times today's load, not a hundred. Beyond that, the requirements will have changed anyway.

5. What is the simplest thing that could work?

A single database and a few stateless servers carry most products much further than people expect. Add complexity only when a number from question one forces you to.

Rule of thumb: every box on the diagram should be there because an answer above demanded it.