From One Server to Planet Scale
The vocabulary lesson — every system design answer is built from these six moves.
You're asked: "Walk me through how you'd scale a web app from one user to ten million." This isn't a product question — it's a vocabulary test. The interviewer wants to see whether you own the standard toolkit: split tiers, load balance, cache, replicate, and do the math.
This case is the foundation for every other case on this site. Master the six moves here and every later design (URL shortener, rate limiter, chat, feed) becomes "pick the right moves from the primer and justify them with numbers."
The meta-skill: at each step, name the bottleneck first, then the fix. "The database is now the bottleneck, so I'll..." is the sentence shape of a strong candidate. Never add a box without saying what problem it solves.
01Day one: everything on one box
Start where every real product starts: one server running the web app and the database, with DNS pointing your domain straight at its IP.
Say this out loud: "I'll start with the simplest thing that works, and add complexity only when a bottleneck forces me to." Interviewers explicitly reward this — drawing twelve boxes for ten users is the classic junior tell.
What one decent box (say 8 cores, 32 GB RAM) actually handles:
- A few hundred requests/sec for a typical dynamic app — thousands if responses are cached or trivial.
- That's genuinely enough for tens of thousands of daily users. Most startups never outgrow stage 2.
What's wrong with it — list the failure modes, because they script the rest of the interview:
- Single point of failure (SPOF): box dies → product is down.
- Resource contention: the app and the DB fight for the same CPU, RAM, and disk I/O.
- No room to grow: when it saturates, your only option is a bigger box — and we'll see why that runs out.
Any component whose death takes the whole system down. The core game of system design is hunting SPOFs and removing them with redundancy — at each stage, ask 'what happens if this box dies?'
Never add infrastructure speculatively. Identify the saturated resource (CPU? disk I/O? connections?), then add the one component that relieves it. Architecture is a sequence of bottleneck removals.
Checkpoint
In an interview, why start by drawing a single server instead of a 'proper' architecture?