What happens to one request

You are in London and tap a pair of running shoes in an online shop, https://shop.example/shoes/42. About a quarter of a second later the page starts to appear. In between, your request has crossed an ocean, passed through several machines and come back.

Two words first. The client is the program that asks: your browser or app. The server is the program that answers. Every exchange is a request from a client and a response from a server. Here is everyone this one request meets:

We follow it in order: find the server, open a connection, pass through the data center, and come back. Then we look at what the trip cost and where it could have failed.

Names like shop.example are for people. Machines on the internet find each other by IP address, a number such as 203.0.113.7. Turning the name into the address is the job of the Domain Name System (DNS), a worldwide directory split across many servers.

So a full walk is several round trips, but it is rare: most lookups are answered from a memory a few milliseconds away.

The TTL is a small trade-off of its own. A long one means faster lookups for everyone. A short one means that when you move the service to a new address, the world finds out sooner.

With the address known, the phone opens a connection. Two separate agreements happen before the request itself can be sent:

• TCP sets up a reliable connection: bytes arrive complete and in order, and lost ones are sent again. It takes three messages, which costs one round trip.
• TLS makes the connection private. The two sides agree on encryption keys, and the server shows a certificate proving it really is shop.example. With TLS 1.3, the current version, that is one more round trip; older TLS 1.2 needed two.

Newer HTTP/3 runs over a transport that folds both handshakes into a single round trip, which is one reason it exists. Either way, the lesson is the same: a new connection is expensive, so clients keep it open and reuse it.

The request reaches the data center. Everything from here on is a short hop, well under a millisecond between machines in the same building:

• Load balancer. It picks one of several healthy app servers. It often ends the TLS here too: it decrypts the request, so the machines behind it do not each carry that work.
• App server. It runs the code: read the request, find product 42, build the page.
• Cache. It asks memory first. Popular products are there, and a hit takes well under a millisecond.
• Database. Only on a miss. Reading from storage takes a few milliseconds more.

The answer travels back the same way: 200 OK and the page's HTML, the text that describes it. But a page is not one file.

So one tap is really dozens of requests. That is why the reuse in the next section matters so much, and why pages that pull files from many different servers feel slow to start.

Add it up for the first tap, with the service 70 ms away and 10 ms of work inside the data center. The DNS figure assumes the resolver already knew the answer.

Now tap a second product a moment later. Three things are still there from the first time:

• The DNS answer, remembered until its TTL runs out.
• The open connection. Browsers keep connections open and send the next request down the same one.
• The TLS session. Even if the connection closed, a client that returns soon can resume the old session and skip part of the handshake.

So the second tap costs one round trip plus the work: about 80 ms instead of 240. The first request is the expensive one. What else adds up, and how to cut it, is the subject of Latency.

The user sees one error. The cause can be at any hop, and the error often tells you which one:

Two things stand out. First, a single request depends on every hop working at the same moment, which is why Availability & reliability multiplies their chances together. Second, the worst failures are often not a dead machine but a slow one: the phone cannot tell a slow server from a lost message, and waits. That puzzle is where Why distributed systems are hard begins.