System design fundamentals
Why this matters
Writing code that works on your laptop is one skill. Designing a system that serves a million people, survives a server dying and doesn't bankrupt the company is another. It's the skill senior engineers are hired for and the core of system design interviews. It rests on a few habits: ask what's really needed, do rough math before building, and know the standard parts and their trade-offs.
- Turn a vague product idea into requirements, including how fast, how big and how reliable
- Estimate traffic, storage and server counts with rough numbers
- Name the standard building blocks and when each one is needed
- Work out availability for parts in a chain and in parallel, and spread data across servers with consistent hashing
Start with requirements
Before designing a house, an architect asks how many people will live there and whether it has to survive hurricanes. Before drawing boxes, pin down two kinds of requirements:
- Functional: what it does. "Users upload a photo; followers see it in their feed."
- Non-functional: how well. Latency, meaning how long people wait ("feed loads in under 200 ms"), scale ("50 million daily users"), availability ("99.9% of the time"), consistency ("a like may take a few seconds to show"), cost and security.
The non-functional ones drive the design. A feed for 1,000 people is one server and a database. For 50 million, it's a different system. Ask, and write the answers down.
Rough numbers
Planning a party, you work out guests times slices before ordering pizza. Back-of-the-envelope math is the same habit, and it tells you which problems are real:
- Requests per second: daily users × requests per user ÷ 86,400 seconds. Peaks are often 2 to 3 times the average.
- Storage: items per day × size × how long you keep them.
- Servers: peak requests per second ÷ what one server handles, plus spares.
Know a few speeds by their order of size:
| operation | about |
|---|---|
| read from memory | 100 nanoseconds |
| read from an SSD | 100 microseconds |
| round trip inside a data center | 0.5 milliseconds |
| round trip across an ocean | 100+ milliseconds |
| one LLM reply | 1 to 30 seconds |
Think of memory as the pen on your desk, disk as a cabinet down the hall, and the network as a letter across town. Memory is about 1,000 times faster than disk, and the network is slower still. That's why caches exist, and why you avoid many sequential network calls on one request.