1 — What happens in a single request
System design sounds abstract, but it comes down to one question asked at growing scale: what happens to a request, and what could go wrong along the way? So the starting point is one request, on one small website.
The parts involved
A website has a few basic parts.
- A client is whatever makes the request, such as a browser or a mobile app.
- A server is a program that waits for requests and answers them. The word also means the computer it runs on.
- A database is a program that stores data safely and lets other programs search it.
The client and server talk over a network, using agreed rules called protocols.
Step by step
Here’s what happens when a browser loads https://example.com/profile/42.
1. Find the address. Computers on the internet are reached by IP address, not by name. The browser asks the Domain Name System (DNS) for the address of example.com. DNS is a global, distributed directory, and the answer is cached at several levels for a set time, called a TTL. Because of that caching, a DNS change can take a while to reach everyone.
2. Open a connection. The browser opens a TCP connection to the server. TCP turns an unreliable network into a reliable, ordered stream of bytes, retransmitting anything that gets lost. Setting it up takes one round trip.
3. Secure it. For HTTPS, a TLS handshake follows, which proves the server’s identity and agrees on encryption keys. TLS 1.3 takes one more round trip. The TLS guide covers this in detail.
4. Send the request. The browser sends an HTTP request:
GET /profile/42 HTTP/1.1
Host: example.comGET is the method, meaning “fetch this”. /profile/42 is the path.
5. Run the application. The server’s code matches the path to a handler, checks who’s asking, and decides what data it needs.
6. Ask the database. The application sends a query:
SELECT name, bio FROM users WHERE id = 42;The database finds the row, using an index if there is one, and returns it.
7. Respond. The application builds a response with a status code, such as 200 for success, 404 for not found or 500 for a server error. The body might be HTML or JSON.
8. Render. The browser reads the page and makes further requests for images, styles and scripts.
Where the time goes
Each step has a cost, and a typical slow page is slow for a boring reason.
| Step | Typical cost |
|---|---|
| DNS lookup | Often zero when cached, otherwise tens of milliseconds |
| TCP setup | One round trip |
| TLS setup | One round trip on TLS 1.3 |
| Application code | Often small, unless it’s doing a lot of work |
| Database query | Under a millisecond to many seconds, depending on indexes |
| Network transfer | Depends on size and distance |
A round trip is limited by distance. Light in fibre takes roughly 50 ms or more to cross a continent and back, and no amount of code changes that. So a server on the other side of the world costs three round trips before the first byte of a page arrives. That’s why content is often served from locations close to users.
What can fail
Every step can fail, and each failure looks different.
| Failure | What the client sees |
|---|---|
| DNS is down or wrong | Name can’t be resolved |
| The server is off | Connection refused or timed out |
| The certificate has expired | TLS error |
| The application crashes | 500 error |
| The database is overloaded | Slow responses, then timeouts |
| The network drops packets | Slowness, because TCP retransmits |
Most of system design is about these failures. Single machines fail, networks lose data, and databases get overloaded. A design describes what happens when they do.
Why one server stops being enough
One server and one database can go a long way. But three limits appear as a site grows:
- Capacity. A machine has a fixed amount of CPU, memory, disk and network.
- Availability. If that one machine fails, the whole site is down.
- Distance. Users far away have higher latency, whatever the machine.
The rest of this track works through what to do about each. Chapters 2 to 4 cover one machine, measurement and scaling out. Chapters 5 to 8 cover data, caches, queues and overload. Chapters 9 to 14 cover the hard distributed problems. Chapters 15 to 19 cover how it all gets built and run.
The takeaway
A system’s behaviour is the sum of many small steps, and each of them can be slow or fail. Clear thinking about a large system starts with being able to describe one request through it, in order.