Module 03 · Lesson 01

How a request travels

From a tap on a phone to a row in a database and back, in about 200 milliseconds.

Beginner 8 min read Updated 2026-11-01

What you will be able to do

  • Trace a single request through every hop it touches
  • Explain what DNS, TLS, and connection reuse cost in round trips
  • Identify which layer to look at when a request is slow
  • Describe a design round answer that starts with the path, not the boxes

The chain, in order

Someone types a URL or taps a button. Before an application server sees anything, several things happen, and each one can be the reason a page feels slow.

1. Name resolution
The client asks a resolver for the IP address behind the hostname. A cold lookup walks root, TLD, and authoritative servers; a warm one answers from the resolver cache in about a millisecond. Your first lever here is a short DNS TTL for things that move and a long one for things that do not.
2. Connection setup
TCP needs a handshake before data flows, and TLS needs another one or two round trips on top. On a 30 ms network path that is already 60-90 ms before the first byte of your JSON. Connection reuse turns that into a one-time cost.
3. The edge
A CDN or reverse proxy terminates TLS close to the user. Static assets should be answered here, never by your application. Requests that genuinely need computation are forwarded inward over a warm connection.
4. The balancer
The load balancer picks a healthy backend, usually in a fraction of a millisecond. If it has to open a new connection to that backend for every request, you have quietly added a handshake to your request budget.
5. The service
Your code authenticates, parses, validates, applies business rules, and calls whatever it needs. This is where the interesting design decisions live; it is also usually the smallest share of latency until you add a synchronous fan-out.
6. The datastore and back
A query runs, a row comes back, the response is serialised, and the same hops replay in reverse. Any cache along the way skips the expensive part.

Where the milliseconds actually go

Same-datacentre round trip
0.5 ms
Two services in one building
Cross-region round trip
70-150 ms
Virginia to Frankfurt is about 80 ms one way
TLS 1.3 handshake
1 RTT
Plus TCP's 1 RTT if the connection is new
SSD random read
0.1 ms
A cache miss at the storage layer
DNS cold lookup
20-120 ms
Cached lookups are near zero

Read that table as a budget. If a page takes 900 ms and the database query takes 4 ms, the database is not your problem. If a service calls five peers in sequence across two regions, the network is the design.

Say this early
"A request comes in through the edge, hits the load balancer, reaches a stateless service which checks the cache and then the database. I will sketch that path and then go deep on the parts that get expensive." One sentence buys you a map the interviewer can follow for the rest of the round.

Fan-out is where latency compounds

One service call is cheap. Ten sequential calls are not, because each waits for the last. The two fixes are structural: call independent dependencies in parallel, and move anything the user is not waiting for out of the request path into a queue.

Sequential:  40 + 40 + 40 + 40 + 40 = 200 ms
Parallel:    max(40, 40, 40, 40, 40) = 40 ms
Async:       return 40 ms, do the rest after responding

A page that loads in 200 ms from five parallel calls will feel better than one that loads in 300 ms from three sequential ones. When you are asked to make something faster, count the hops before you touch the database.

Stateless services make the path repeatable

If any server can serve any request, the balancer is free to send traffic anywhere, restarts are invisible, and scaling is adding identical boxes. Sessions belong in a shared store or a signed token, not in process memory. The moment one request must return to the same machine, you have created a scaling problem and an availability problem at the same time.

  • Keep request handlers stateless; push state to a cache, a database, or the client.
  • Make every hop observable: a request id that travels with the call is what makes a slow request traceable later.
  • Terminate TLS at the edge so your services speak plain HTTP inside a trusted network.
  • Set timeouts and budgets per hop, not just per request, or one slow dependency becomes your whole latency.

Worth remembering

  • A request is a chain of hops; the total latency is the sum of each hop's work plus network time.
  • Connection setup, TLS handshake, and DNS are one-time-ish costs that connection pooling and caching hide.
  • The first thing to ask about a slow path is where the time is spent, not which database to swap.
  • Explaining a request path out loud is the cheapest way to prove you understand the system you just drew.

Checkpoint

Answer all 3 questions to finish the lesson.
1. A page takes 900 ms. The database query is measured at 4 ms. What is the most useful next question?
The query is 0.4% of the time. Measure the path — DNS, handshakes, network, fan-out — before changing a component that is not the bottleneck.
2. Five independent backend calls each take 40 ms. Sequential versus parallel changes the total to roughly:
Sequential calls add up (5 × 40). Independent calls issued together cost the slowest one, about 40 ms.
3. Why do stateless services make horizontal scaling straightforward?
Statelessness is what lets a balancer treat instances as interchangeable; sticky sessions reintroduce coupling between a user and a machine.
← PreviousDesign principles that survive scrutiny