Foundations

System design is planning how the parts of a software system fit together so it keeps working as more people use it. Code decides how a feature works. Design decides where the data lives and which machines do the work. It also plans for the day a million people show up at once.

In an interview, a design question is a conversation, not a test with one right answer. You're judged on how you reason: asking the right questions, making sensible estimates, and explaining the trade-offs of each choice.

How a request travels

Every design builds on one basic trip. When you type a web address and press Enter, your browser is the client, and the computer that answers is the server.

1. The browser asks DNS (the Domain Name System) for the server's address. DNS works like a phone book: it turns a name like example.com into a number, the IP address.
2. The browser connects to that address and sends an HTTP request, like "GET me the home page".
3. The server runs its code. It usually needs stored data, so it asks a database.
4. The server sends back a response: a web page, or data such as JSON. The browser shows it.

Each request carries a method that says what it wants: GET reads something, POST creates something, PUT replaces it, and DELETE removes it. Each response carries a status code: 200 means it worked, 404 means not found, and 500 means the server failed.

HTTP is stateless: each request stands alone, and the server doesn't remember the last one. Anything that must last between requests, like who is logged in, travels with the request or lives in a store. That idea comes back when we add more servers.

Speeds every engineer should know

Designs are shaped by how long things take. These are rough, but the gaps between them matter more than the exact numbers:

Read from memory

100 ns

Read 1 MB from memory

10 µs

Read from an SSD

100 µs

Round trip in one data center

0.5 ms

Read 1 MB from an SSD

1 ms

Spinning disk seek

10 ms

Round trip, US to Europe

150 ms

A nanosecond (ns) is a billionth of a second, a microsecond (µs) a millionth, and a millisecond (ms) a thousandth. Memory is about a thousand times faster than an SSD. A trip across the world takes over a million times longer than a memory read.

Three lessons follow. Keep often-used data in memory. Avoid many round trips when one will do. And put servers close to the people who use them.

Back-of-the-envelope estimates

Interviewers often ask for rough numbers: how many requests per second, how much storage. You don't need a calculator, only a few handy facts:

• A day has 86,400 seconds, about 100,000. So a million requests a day is about 12 a second.
• Traffic isn't even across the day. The busiest hour, the peak, is often two to three times the average.
• A kilobyte (KB) is a thousand bytes, a megabyte (MB) a million, a gigabyte (GB) a billion, and a terabyte (TB) a trillion.

Here's a full estimate for a service with 10 million daily users, each making 2 posts a day of about 1 KB:

Round freely: "about 200 writes a second, under 1,000 at the peak, around 7 TB a year" is a great answer. What matters is showing the steps, so the interviewer can follow and correct your assumptions.

Two kinds of requirements

Before designing anything, pin down what it must do. Functional requirements are the features: "users can post a photo", "users can follow each other". Non-functional requirements are the qualities: how fast, how big, how reliable.

The most common qualities are scale (how many users and requests), latency (how fast each request must be), availability, and consistency. Availability is the share of time the service works, often given in "nines":

• 99% is down about 3.7 days a year.
• 99.9% is down about 9 hours a year.
• 99.99% is down about 53 minutes a year.

Each extra nine costs a lot more to build. Consistency is whether everyone sees the same data at the same moment. A bank balance needs it, and a like count can lag for a few seconds.