Learn to identify the client and server, trace a request from user action to rendered response, and locate the latency and failure points along the way. By the end, you will have a baseline model for understanding what changes when DNS, load balancers, caches, CDNs, or other layers are added.
When a user taps a button or presses Enter, the visible action hides a long chain of work. A client must find a server, establish communication, send a request, wait for processing, receive a response, and often render the result. Once you can name each step, latency and failures stop looking mysterious: you can ask which hop is slow, which component owns it, and what changed when another layer was inserted.
The asymmetry that explains the model
The client–server model begins with a simple direction: the client initiates requests and the server responds. The client owns the user’s context, such as the device, session, and current UI state. The server owns shared state, such as data, business logic, and authentication. Each side has information and responsibilities the other side cannot replace.
Design a platform-scale distributed rate limiter55 min
Critique: find the failure modes in a given design45 min
This direction is a design choice, not a law of physics. The normal HTTP model is request-initiated by the client, but architectures can deliberately stress or change that pattern with mechanisms such as server-sent events or WebSockets. Naming the client and server is therefore a useful first move in a design conversation: it makes clear who initiates communication, what travels over the wire, and where state lives.
Walking a request through the network
Before application code runs, the client must resolve the server’s hostname. DNS turns a name such as api.example.com into an IP address. A cold DNS lookup can add tens of milliseconds and can even dwarf the application processing time, so skipping DNS in a latency budget can lead you to investigate the wrong component. DNS TTL tuning is therefore a real performance lever.
The client then establishes a TCP connection with a three-way handshake: SYN, SYN-ACK, and ACK. This costs another round-trip before HTTP begins. With HTTPS, a TLS handshake is added on top for certificate exchange and cipher negotiation. These setup steps explain why connection reuse matters: keep-alive and HTTP/2 multiplexing can avoid repeatedly paying the full connection cost.
A client must complete name resolution and connection setup before the server can process the HTTP request and return the first response byte.
Follow the path from DNS and connection setup through server processing to see which stages occur before the first response byte.
Only after these steps does the client send the HTTP request line, headers, and optional body. In a browser, the Network tab exposes this sequence as a timing waterfall. A request’s breakdown can show DNS Lookup, Initial connection, SSL, and Waiting (TTFB) as separate slices. The waterfall is not just a performance report; it is a visible representation of the request lifecycle.
CHECK YOUR UNDERSTANDING
What happens between entering a URL and the browser sending the HTTP request?
SHOW ANSWERHIDE ANSWER
The operating system first resolves the hostname through DNS. The client then performs the TCP three-way handshake. If the connection uses HTTPS, it performs the TLS handshake as well. Only after those stages does the client send the HTTP request line, headers, and optional body.
What the server does with the request
The request arrives at a network interface, moves up the operating system’s network stack, and reaches the server process’s accept queue. Under load, congestion at this point can become an early bottleneck. The application framework then parses the method, path, headers, and body, and routes the request to a handler.
The handler usually performs several distinct activities: it validates input, checks authentication, reads from or writes to a datastore, calls downstream services, and serializes a response. Not every request needs every activity, but each one is a potential latency spike or failure point. Keeping the steps explicit lets you measure and optimize them independently.
The response trip back and rendering
After processing, the server writes a response consisting of a status line, headers, and body back down the same TCP connection, or a new one if connection reuse is not in play. The client receives bytes incrementally. A browser can begin parsing HTML before the full body arrives, so streaming and chunked transfer encoding can affect how quickly the user perceives progress.
Two timing measures describe different parts of this experience. Time to First Byte (TTFB) measures server and network latency up to the first byte of the response. Total Page Load includes everything through client-side rendering. If TTFB is fast but rendering is slow, blaming the server will send the investigation in the wrong direction.
The round-trip time between the client and server also creates a physical floor. Code optimization cannot eliminate the distance that data must travel. For example, a server in Virginia responding to a user in Sydney faces roughly 170 ms of minimum RTT, while a CDN edge node in Sydney can serve a cached response in roughly 5 ms. The application may be the same, but the lifecycle is radically different because the response is served closer to the user.
Serving a cached response near the user can remove much of the long geographic path to the origin server.
Compare the long origin path with the shorter cached edge path and notice how geography changes the network portion of the lifecycle.
CHECK YOUR UNDERSTANDING
A waterfall shows TTFB at 800 ms, while DNS and connection time are both under 5 ms. Where does the problem most likely live?
SHOW ANSWERHIDE ANSWER
The problem most likely lives after connection setup and before the first response byte: server-side processing or a downstream operation such as authentication, a datastore query, or another service call. DNS and connection establishment are unlikely to explain the delay, so investigate the server handler and its sub-steps.
Where the simple model gets stressed
A single server answering every client is the simplest architecture, and it is also the first arrangement that breaks as scale, failure, and latency become concerns. The common response is to insert components between the client and server: load balancers, caches, CDNs, and API gateways. Each added component creates another hop in the lifecycle, with its own latency and failure mode.
A scaled system inserts multiple client–server relationships between the user’s device and shared backend data.
Read each arrow as a separate client–server relationship, from the user’s device through intermediary layers to the backend data.
Statelessness is the design principle that makes this model easier to scale. If a server holds no per-client state between requests, any server instance can handle any request. That allows a request to move among instances in a fleet without requiring one particular machine to remember the client’s previous request.
CHECK YOUR UNDERSTANDING
What does it mean for a server to be stateless, and why does that help horizontal scaling?
SHOW ANSWERHIDE ANSWER
A stateless server does not retain per-client state between requests. Because any instance can handle any request, a fleet can distribute requests across server instances without requiring a particular client to return to the same machine.
Carry the lifecycle into every design
Use this model as a repeatable set of questions: Who is the client? Who is the server? What travels over the wire? Which steps happen before application code runs? Which component owns each piece of state? Where can latency or failure appear? These questions keep an architecture concrete even when the system contains several layers.
For a timeline request, the path might be a phone, then a CDN edge serving cached assets, then a load balancer, then one of many stateless API servers, then a distributed cache, and finally a database cluster. Each arrow represents a client–server relationship at a different scale. Once you can trace the simple request, those additional relationships become understandable rather than mysterious.
KEY TAKEAWAYS
The client initiates the normal HTTP request, while the server owns shared data, business logic, and authentication.
A request lifecycle includes DNS, TCP, TLS when using HTTPS, the HTTP request, server processing, the response, and client rendering.
Every lifecycle stage can add latency or fail, so separate timing measures such as DNS, connection time, TTFB, and total load time.
Stateless servers scale more easily because any instance can handle any request.
Load balancers, caches, CDNs, and gateways add hops; evaluate each hop for both latency and failure modes.
A1 · Client–server model & the request lifecycle — System Design