Almost every system you will design is, at bottom, a machine that answers requests coming over the internet. Before you can reason about load balancers, caches or CDNs, you need a clear picture of the path a single request already takes.
That path has more steps than most people expect, and each step is a place where latency accumulates and things fail. Nearly every topic later in this course is an attempt to make one of these steps faster or more reliable.
The journey of one request
A browser is asked for https://example.com/profile. Five things have to happen before a pixel changes.
| Step | What happens | Typical cost |
|---|---|---|
| DNS lookup | Turn the name into an IP address | 0–100 ms, usually cached |
| TCP handshake | Establish a connection | One round trip |
| TLS handshake | Agree on encryption | One to two round trips |
| HTTP request | Ask for the resource | One round trip, plus server time |
| Render | Parse, fetch sub-resources, paint | Often the largest share |
Notice that three of the five are round trips before a single byte of content moves. On a connection with 100 ms of latency, you have spent 300 ms before the server has even begun to think. This is why latency, not bandwidth, dominates the experience of most web applications — and why so much engineering effort goes into avoiding these steps rather than speeding them up.
Names to addresses
Computers route by IP address; humans use names. DNS is the lookup that bridges them, and it is a hierarchy: a resolver asks the root, which points to the .com servers, which point to the servers authoritative for example.com.
That full walk is slow, so nearly every result is cached — in the browser, the operating system, and the resolver — for a duration the domain owner controls. This makes DNS fast in the common case, and it makes DNS changes slow to take effect. That second property has real consequences: DNS is a poor emergency switch, because clients keep using the old answer until their cached copy expires.
Connection and encryption
TCP provides an ordered, reliable byte stream over an unreliable network. It gets that by numbering data, acknowledging receipt, and retransmitting what goes missing — which is also why it must establish a connection first, costing a round trip before any data flows.
TLS then negotiates encryption on top, costing one or two more. It gives you three things worth naming separately: confidentiality (nobody can read it), integrity (nobody can alter it undetected), and authentication (you are talking to who you think).
The expensive part is the setup, not the ongoing encryption. This is precisely why connections are reused rather than opened per request — an idea you will meet again as connection pooling on the server side.
The request itself
HTTP is a text-shaped protocol: a method, a path, headers, and an optional body. The response is a status code, headers, and a body.
Two properties shape architecture more than anything else about it.
HTTP is stateless. Each request carries everything needed to serve it; the protocol remembers nothing between them. Sessions, cookies and tokens all exist to reintroduce state on top. Statelessness is also what makes horizontal scaling possible — if no request depends on which server handled the last one, any server can handle any request.
Methods carry meaning. GET should not change anything, which is what allows caches to store responses and clients to retry freely. A GET that mutates state breaks assumptions made by browsers, proxies and CDNs alike.
Where the response actually comes from
A modern request rarely reaches your server. Between browser and origin sit several layers, each of which may answer without consulting the next:
Diagram, as text
- Browser cache leads to DNS
- DNS leads to CDN edge
- CDN edge leads to Load balancer
- Load balancer leads to App server
- App server leads to Cache
- Cache leads to Database
Every arrow is a chance to stop early. The browser cache is free and instant. The CDN edge is close to the user. The server-side cache avoids the database. The fastest request is the one that never reaches you, and much of system design is arranging for exactly that.
Read that chain again in reverse and you have the syllabus for the High-Level Design module.
Before that, it is worth seeing where the time actually goes. A first visit pays for every step; a repeat visit on a warm connection skips most of them.
Where the time goes on one page load
- First visit
- Repeat visit
The data as a table
| Time | First visit | Repeat visit |
|---|---|---|
| DNS | 30 ms | 0 ms |
| TCP | 40 ms | 0 ms |
| TLS | 60 ms | 0 ms |
| Server work | 120 ms | 120 ms |
| Download | 180 ms | 40 ms |
This is why connection reuse and caching matter more than shaving milliseconds off server work: on a first visit the setup costs more than the response does, and on a repeat visit they vanish.
What this means for design
Three consequences worth carrying forward.
Round trips dominate. Reducing the number of sequential network hops usually beats optimising any single one. This is the argument for caching, for connection reuse, and for not making a client fetch five endpoints to render one screen.
Distance is latency. Light in fibre is fast but finite; a round trip across the world costs well over 100 ms no matter how good your code is. Putting content near users is the only fix, which is what a CDN is for.
Statelessness enables scale. Keep request-handling servers free of local state and you can add and remove them freely. Store state deliberately — in a database, a cache, or the client's token — rather than accidentally in a server's memory.
Check your understanding
Common mistakes
Assuming bandwidth is the bottleneck. For most applications it is round-trip latency, and the fixes are entirely different.
Treating GET as ordinary. A GET with side effects will be retried, prefetched and cached by things you do not control.
Returning 200 for failures. It blinds caches, retry logic and monitoring simultaneously.
Using DNS as a failover switch. Cached answers mean the change lands slowly and unevenly.
Keeping session state in server memory. It works with one server and breaks the moment there are two.
Testing only on localhost. Zero latency and zero packet loss hide every problem this page describes.
Practice
A colleague reports that your site 'feels slow in Australia' and proposes upgrading the server's CPU. Your servers are in Ireland and sit at 15% CPU. Explain why the upgrade will not help, and name two changes that would.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Work out the floor imposed by distance before considering anything the server does.
Show a strong answer
The upgrade cannot help because the server is not the bottleneck. At 15% CPU it is idle, and the time the user waits is mostly time on the wire.
Ireland to Sydney is roughly 17,000 km. Light in fibre travels at about 200,000 km/s, so one leg is around 85 ms and a round trip around 170 ms at the theoretical minimum — real routes are longer. With DNS, TCP and TLS each costing a round trip before the request is even sent, an Australian user has spent over half a second before your idle server begins to think. No CPU makes light faster.
Two changes that do help:
- Put content near the user. A CDN edge in Sydney answers static assets locally, removing the round trip entirely for most of the page.
- Remove round trips. Reuse connections rather than re-handshaking, and collapse the five API calls the page makes into one, so the fixed latency cost is paid once instead of five times.
The general rule: when latency dominates, reduce the number of sequential hops before optimising any single one.
An endpoint that charges a customer is implemented as GET /api/charge?amount=500. List three separate things that will go wrong, each caused by a different part of the web stack.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Think about who else is allowed to issue a GET on the user's behalf, and when.
Show a strong answer
Three failures, from three different layers:
- Caches will store the response.
GETis defined as safe and cacheable, so a browser cache, a proxy or a CDN may serve a stored response to a later request — or treat the URL as a stable resource. The charge appears to succeed without ever reaching you. - Clients and infrastructure will retry it freely. Because
GETis assumed to have no side effects, browsers prefetch links, crawlers follow them, and retry logic repeats them after a timeout. Each retry is another charge. - The URL leaks and can be replayed. Query strings land in browser history, server access logs and
Refererheaders sent to third parties. Anyone who reads one can re-trigger the charge by visiting it.
The fix is POST with the amount in the body, plus an idempotency key so a genuine retry is recognised as the same charge rather than a new one.
Key takeaways
- A request costs DNS, TCP, TLS, then HTTP — three round trips before content moves, which is why latency dominates.
- DNS is fast because it is cached, and slow to change for exactly the same reason.
- TLS gives confidentiality, integrity and authentication; the cost is in the handshake, so connections are reused.
- HTTP is stateless, which is what makes horizontal scaling possible — state must be stored deliberately.
- Status codes are an interface that caches, proxies and monitoring act on.
200with an error body breaks all three. - Every layer between browser and database is a chance to answer early — the fastest request never reaches your server.
- The network can be slow, fail, or succeed invisibly. That ambiguity is the root of retries, timeouts and idempotency.
Further reading
- RFC 9110, HTTP Semantics — the authoritative definition of methods, status codes and caching rules.
- RFC 1034 and RFC 1035, Domain Names — concepts and specification for DNS resolution.
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 — how the handshake was reduced to one round trip.
- Ilya Grigorik, High Performance Browser Networking (O'Reilly, 2013) — latency, TCP and TLS from the browser's point of view.
- Stuart Cheshire, "It's the Latency, Stupid" (1996) — the classic short argument for why bandwidth is rarely the problem.