How a request travels: from typing a URL to seeing the page

Every system you'll ever design is a machine for answering requests. Before choosing databases or caches, you need a clear picture of what one request actually does: who it talks to, in what order, and where the time goes. It turns out most of the time isn't spent computing anything. It's spent waiting for messages to cross the network.

1. The idea

On the internet, the program asking is the client (a browser, a phone app, or another service) and the program answering is the server. They follow a short, fixed sequence every time a client talks to a server it isn't already connected to:

Steps 1–3 only happen when there's no connection yet. A browser keeps the connection open and reuses it for the next requests, which then cost just step 4. That single fact explains a large share of web performance work.

One more idea matters from day one: HTTP is stateless. Each request carries everything the server needs (who you are, usually as a token in a header, and what you want). The server doesn't have to remember the previous request. That's what lets you put many identical servers behind a load balancer and send each request to any of them (Module 08).

2. How it works

Press Play to follow a first visit to https://photos.example.com/photos/42 from a user whose round trip to the data centre takes 60 ms. The bar at the bottom adds up where the time goes. The numbers are realistic but illustrative.

HTTP in sixty seconds

An HTTP request is plain structured text (HTTP/2 and HTTP/3 send the same information in a compact binary form):

GET /photos/42 HTTP/1.1
Host: photos.example.com
Authorization: Bearer eyJhbGciOi...      ← who you are (a token, not a user ID you typed)
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60                ← how long others may reuse this answer

{"id": 42, "title": "Sunset", "url": "https://cdn.example.com/p/42.jpg"}

The 4xx vs 5xx split matters in design: clients should not retry most 4xx errors (the request itself is wrong), but may retry 5xx and 429 errors after waiting. You'll build on this in Module 24.

3. Try it yourself

Where does the time go?

Change the user's distance from the server and the conditions of the request. Watch which part of the bar grows. Try a first visit from the other side of the world, then the same request on a reused connection.

Model: DNS miss costs about one round trip to a nearby resolver plus 20 ms; TCP and TLS 1.3 cost one round trip each (TLS 1.2: two); HTTP/3 combines connection and encryption setup into one round trip; transfer assumes a 50 Mbit/s connection and ignores TCP slow start, which makes large first responses slower still.

Measure a real one

Your terminal can show the same breakdown for any website. curl's -w option prints timings (in seconds, measured from the start):

curl -o /dev/null -s -w 'dns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}  first byte %{time_starttransfer}  total %{time_total}\n' https://example.com

Run it twice: the second DNS time is usually near zero because the answer was cached. In a browser, open DevTools → Network, click a request, and open the Timing tab for the same picture.

4. Why it matters in design

5. In real systems

HTTP versions in 2026. HTTP/1.1 sends one request at a time per connection, so browsers open several connections. HTTP/2 sends many requests at once over one connection. HTTP/3 runs over QUIC, which uses UDP and combines the connection and TLS handshakes into one round trip; it also copes better with lossy mobile networks. Most large sites and CDNs serve HTTP/2 and HTTP/3 today. Module 06 goes deeper.

In an interview you rarely draw DNS or TLS. You do need this picture in your head: it tells you why a CDN helps, why a stateless app tier scales, and why a request that calls five services in a row is slow.

The technologies up close

6. Remember it

7. Common mistakes

8. Design exercise (20 minutes)

1. Draw the path. On paper, draw every hop for opening one screen of an app you use daily: client, DNS, CDN, load balancer, app servers, cache, database. Mark which hops are skipped on the second request.
2. Count the trips. For a user 150 ms away, estimate the time to the first byte on a first visit with TLS 1.3, then on a reused connection. Then estimate it with HTTP/3.
3. Measure three sites. Run the curl command from section 3 against three websites, one of them hosted far from you. Which part of the time is largest for each?
4. Move the content. Decide which parts of your app's screen could be served from a CDN near the user, and which must come from the origin servers. Say why in one line each.
5. Write it down. Three bullets in your design notebook: find–knock–lock–ask, round trips beat bandwidth, stateless servers scale.

9. Self-check quiz

10. Go deeper