How a Web Request Travels: DNS, TCP, TLS and HTTP for System Design

You tap a link to a photo on Pixly. Half a second later it appears. In that half second your phone found an address for a name, opened a connection across several networks, agreed encryption keys with a server it had never met, sent a request, and waited while that request passed through a load balancer, an application server, a cache and maybe a database, before the answer came all the way back.

You do not need to be a network engineer to design systems. But you do need a working model of this path, because almost every design decision about latency, scaling and failure is really a decision about one of these hops. This article gives you that model.

• The steps a request goes through, from the client to the database and back.
• What DNS does, how caching and TTLs work, and how DNS is used for routing and failover.
• What TCP and TLS handshakes cost, and why round trips matter so much.
• What HTTP requests and responses contain, and how HTTP/1.1, HTTP/2 and HTTP/3 differ at a high level.
• How to build a simple latency budget and see where time goes.
• Rough latency numbers worth remembering.
• Where along the path requests fail, and what that means for design.

 Phone / browser   |  1. DNS lookup: "photos.pixly.example" -> IP address   |  2. TCP connection to that address (handshake)   |  3. TLS handshake (encryption keys, certificate check)   |  4. HTTP request: GET /photos/123   v CDN / edge server ------ static file cached here? return it (fast path)   |  (cache miss or dynamic request)   v Load balancer ---------- picks a healthy application server   v Application server ----- authenticates, runs business logic   |        \   |         \--> Cache (is the answer already in memory?)   v Database --------------- reads or writes the data   |   v Response travels back the same way: app -> load balancer -> edge -> client

Steps 1 to 3 happen before your application code sees anything. They are often skipped in interviews, yet for users far from your servers they can take longer than everything else combined.

Computers route traffic to IP addresses (for example 203.0.113.10), but people use domain names (photos.pixly.example). The Domain Name System (DNS) is the distributed directory that maps one to the other. Its design is described in RFC 1034 (Domain Names: Concepts and Facilities).

1. Your device asks a recursive resolver, usually run by your internet provider or a public DNS service: "What is the address of photos.pixly.example?"
2. If the resolver does not have the answer cached, it asks a root server, which points it to the servers for .example.
3. Those top-level domain (TLD) servers point it to the authoritative servers for pixly.example, which are run by Pixly or its DNS provider.
4. The authoritative server returns the address. The resolver caches it and returns it to your device, which also caches it.

Device -> Recursive resolver -> Root -> TLD (.example) -> Authoritative (pixly.example)   <------------------- answer, cached for TTL seconds ---------------------

Every DNS answer comes with a TTL (time to live), in seconds. Resolvers and devices may reuse the answer until it expires. This makes almost all lookups fast, because most are answered from a nearby cache.

TTL is a trade-off you will meet again:

Managed DNS services do more than answer a fixed address. Amazon Route 53, for example, is described in its documentation as offering domain registration, DNS routing and health checking (What is Amazon Route 53?). Similar features exist in other providers' DNS services. Common uses in system design:

• Geographic or latency-based routing: users in India get the address of servers in an Indian region; users in Europe get European servers.
• Weighted routing: send 5% of traffic to a new deployment to test it.
• Failover: health checks watch your servers; if the primary region stops responding, DNS starts returning the address of a standby.

Keep the TTL trade-off in mind: DNS failover is only as fast as clients' caches expire. That is why many systems use DNS for coarse routing between regions and use load balancers for fast failover within a region (article 08).

Most web traffic today runs over TCP (Transmission Control Protocol), which gives the two ends a reliable, ordered stream of bytes over an unreliable network. It handles lost packets (by resending), reordering (by sequence numbers) and pacing (so a fast sender does not overwhelm a slow network). HTTP/3 is the exception: it runs over QUIC on top of UDP, covered below.

Before any data flows, TCP performs a three-way handshake: the client sends a SYN, the server replies SYN-ACK, the client sends ACK. That costs one round trip before the client can send its request.

A round trip time (RTT) is how long a message takes to go to the other end and back. It is set mostly by physical distance (light in fibre is fast but not instant) and by the number of network hops. Rough orders of magnitude:

These are rough figures for reasoning, not measurements of any particular network. Real values depend on routes, mobile networks and congestion. The point is the ratio: crossing continents costs hundreds of times more than staying inside a data centre.

HTTPS is HTTP inside TLS (Transport Layer Security). TLS gives three guarantees:

• Confidentiality: nobody on the path can read the traffic.
• Integrity: nobody can change it without detection.
• Authentication: the client can check, using the server's certificate, that it is really talking to photos.pixly.example and not an impostor.

To get there, client and server perform a TLS handshake to agree on keys. In TLS 1.3, the current version, a full handshake takes one round trip, and a client resuming an earlier session can even send data in its first flight, called 0-RTT data, though the specification warns that such data can be replayed (RFC 8446, TLS 1.3). Older TLS 1.2 handshakes took two round trips.

Decrypting traffic costs CPU and requires the private key. Many systems terminate TLS at the edge: the CDN or load balancer decrypts the request and forwards it to application servers over the internal network. This centralises certificate management and offloads work from the app servers.

The trade-off: traffic between the load balancer and the app servers is then plain text unless you re-encrypt it. Systems handling sensitive data often re-encrypt internal traffic too, so that a compromised internal machine cannot read everything. Article 28 returns to this.

Now, finally, the actual request. HTTP is a request-response protocol whose meaning is defined in RFC 9110 (HTTP Semantics). A request has:

• a method (GET, POST, PUT, PATCH, DELETE and others) saying what kind of action it is;
• a target, such as /photos/123;
• headers: key-value metadata such as Authorization, Accept, Cache-Control;
• an optional body, for example the JSON of a new comment.

A response has a status code, headers and an optional body:

GET /photos/123 HTTP/1.1Host: api.pixly.exampleAuthorization: Bearer (token)Accept: application/jsonHTTP/1.1 200 OKContent-Type: application/jsonCache-Control: private, max-age=60{"id": 123, "owner": "asha", "caption": "Sunset", "likes": 1203}

Status codes fall into families: 2xx success, 3xx redirection, 4xx a problem with the request (the client should change something), 5xx a problem on the server. Article 04 covers which code to use when.

Each HTTP request stands alone. The server is not required to remember anything about earlier requests from the same client. If the application needs continuity (who is logged in, what is in a cart), that state must either travel with each request (a cookie or token) or be looked up in a shared store (a database or cache).

This is not a limitation to work around; it is what makes large systems possible. If no application server holds private memory of a user, then any server can handle any request, and a load balancer can spread requests freely. Article 08 builds on this.

For system design you rarely need more than this. The practical lessons: reuse connections instead of opening a new one per request, and know that newer protocols reduce handshake and loss-related delays, which matters most on mobile networks and long distances.

Once the request leaves the client:

1. CDN or edge server. If the request is for a static file (an image, a script) that the edge has cached, it answers immediately from a location close to the user. Otherwise it forwards the request towards your servers, often over a faster, better-connected network. Article 10 covers CDNs.
2. Load balancer. It picks one healthy application server and forwards the request. It may also terminate TLS, add headers such as the original client address, and enforce limits. Article 08 covers load balancers.
3. Application server. It authenticates the caller, validates the input and runs the business logic. To answer, it may check a cache (article 09), query a database (articles 12 to 17), call other internal services, or put a message on a queue for background work (article 11).
4. The response returns along the same path. The browser may then fetch dozens more resources (images, scripts, API calls) for one page, each with its own path through this system.

Inside your data centre, each internal hop costs well under a millisecond of network time. But they add up, and every hop is a place where a request can wait or fail.

A latency budget splits a target ("the photo page loads in under 500 ms") into the time each step may take. Let us build one for a first visit, with a fresh connection.

Assumptions (illustrative, not measurements):

• The user is in Bengaluru.
• Option A: Pixly's servers are in a region in Mumbai, about 20 ms RTT away.
• Option B: Pixly's servers are in the eastern US, about 250 ms RTT away.
• The DNS answer is already cached on the device (common for repeat visits; a cold lookup would add more).
• TLS 1.3 with a full handshake (1 RTT).
• Server-side work (load balancer, app, cache, database) takes 50 ms in total.

Look at Option B. The server-side work is 50 ms, the same as in Option A, yet the user waits 800 ms. Distance multiplied by round trips dominates. No amount of database tuning fixes that. What does fix it:

• Serve from closer: a region near the users, or a CDN edge for static content.
• Reuse connections: on the second request over the same connection, TCP and TLS are already done, so Option B drops to 250 + 50 = 300 ms.
• Avoid sequential round trips: if the page needs three API calls one after another, each costs a full RTT. Combine them into one call, or make them in parallel.
• Use protocols that save handshakes, such as TLS 1.3 and HTTP/3, especially for mobile users.

This is why "chatty" APIs (many small calls to build one screen) are a design smell for mobile clients far from the server.

You do not need exact figures, but you should know the orders of magnitude, because they tell you which operations are worth worrying about. The table below gives rough values in the spirit of the widely shared "latency numbers every programmer should know" list; an interactive version by Colin Scott shows how such estimates change by year and makes clear they are extrapolations, not measurements (Latency numbers).

What to take from this:

• Memory is far faster than disk, and disk far faster than crossing the world. That is the whole case for caches (keep hot data in memory) and CDNs (keep content near users).
• One cross-continent round trip costs as much as hundreds of thousands of memory reads. Optimising code while ignoring network round trips is usually optimising the wrong thing.
• Inside a data centre, a network call is cheap but not free. A request that makes 50 sequential internal calls at half a millisecond each spends 25 ms just on network time.

When you design, walk the path and ask "what if this step fails?"

Two habits follow from this table and will appear in every case study:

1. Every network call gets a timeout. Without one, a slow dependency holds threads and connections forever, and slowness turns into an outage (remember Little's Law from article 02).
2. Every component in the critical path is a possible point of failure. Fewer hops in the synchronous path means fewer ways to fail.

• Ignoring the network in latency estimates. Server time is often the smaller part for distant users.
• Assuming DNS failover is instant. Cached answers keep old addresses alive until their TTL ends.
• Opening a new connection for every call between services, paying handshakes each time.
• Designing chatty APIs for mobile clients, so each screen costs several sequential round trips.
• Keeping user state in one server's memory, which breaks as soon as there are two servers.
• Forgetting certificate expiry, a common and entirely avoidable cause of outages.
• No timeouts on outbound calls.

You rarely need to explain TCP in detail. What earns credit is using the model:

• "Users are in India, so I'll deploy in an Indian region and put static images behind a CDN to cut round-trip time."
• "The mobile home screen makes one aggregated call instead of five, because each sequential call costs a full round trip on a mobile network."
• "Application servers are stateless; sessions live in a shared store, so the load balancer can send any request anywhere."
• "TLS terminates at the load balancer; internal traffic is re-encrypted because we handle payment data."

• Next: API Design for System Design: REST, Status Codes, Pagination and Versioning designs what travels inside those HTTP requests.
• For a gentler introduction, How a Website Works: From Typing a URL to Seeing the Page covers the same path with less detail.
• Later in the course: load balancers (article 08), CDNs (article 10) and regional failover (article 24) build directly on this model.