Prologue
The Lifecycle of a Software Request
Tracing an HTTP request from client click to rendered response — and every hand-off in between.
Why This Exists
Why This Lesson Comes First
Typing a URL and seeing a page feels instant and singular, but it’s actually a sequence of separate network round trips to separate systems (DNSDomain Name System. The distributed lookup system that translates human-readable domain names into the IP addresses machines actually use to route traffic. servers, routers, the destination server), each with its own latency, and treating it as one atomic step hides where a real system actually spends its time.
Without understanding the request lifecycle, it’s easy to misplace blame for slowness, e.g. optimizing server code when the real cost is a slow DNS lookup or an unnecessary extra TLSTransport Layer Security. The negotiation that establishes an encrypted channel over an existing TCP connection, including certificate verification and shared key derivation, which is what turns HTTP into HTTPS. handshake, or to design a system that repeats expensive steps (like re-resolving DNS or re-negotiating TLS) that could have been reused.
System design interviews frequently probe this directly (‘walk me through what happens when a user hits your API’), and a shaky answer here reads as a gap in fundamentals no matter how good the higher-level architecture is.
A software request begins the moment a user interacts with an interface and ends when that user perceives the result. At its core, this journey is a series of hand-offs between specialized components, each responsible for transforming, routing, or retrieving information.
When a user clicks "Search" or "Login," they are triggering an HTTP request. This signal moves from the client — a browser or mobile app — through several layers before a response is returned.
Think Of It Like
An Office Building With No Directory
Getting a web page loaded is like ordering food through a chain of intermediaries in an old-fashioned office building with no directory. First you ask the front desk which floor the company you want is on (DNSDomain Name System. The distributed lookup system that translates human-readable domain names into the IP addresses machines actually use to route traffic.). Then you walk to that floor and knock, and someone has to confirm you’re allowed in and agree on a shared language before you can talk business (the TCPTransmission Control Protocol. The SYN, SYN-ACK, ACK exchange that establishes a reliable, ordered connection between client and server before any application data is sent. and TLSTransport Layer Security. The negotiation that establishes an encrypted channel over an existing TCP connection, including certificate verification and shared key derivation, which is what turns HTTP into HTTPS. handshakes). Only after all of that do you actually hand over your order and get a response (the HTTP request and response).
Every one of those steps takes real time, and if you have to repeat the whole walk for every single question, you’re wasting most of your visit on logistics instead of getting an answer.
The Map
The Chain of Systems Behind One Request
End to End
The Request Lifecycle
The client constructs an HTTP request, including a method (GET, POST, etc.), headers, and a payload.
Before the client can send data, it must resolve the domain name (e.g., api.example.com) into an IP address using DNSDomain Name System. The distributed lookup system that translates human-readable domain names into the IP addresses machines actually use to route traffic..
With an IP address in hand, client and server run the TCP handshakeTransmission Control Protocol. The SYN, SYN-ACK, ACK exchange that establishes a reliable, ordered connection between client and server before any application data is sent. to open a reliable, ordered connection. That is one full round tripOne full cycle of a message sent and its reply received, the basic unit of network latency, since several handshake steps each cost a full round trip before useful data moves. spent before any request data moves.
For HTTPS, encryption is negotiated on top of that connection: the server proves its identity with a certificate and both sides derive a shared key. The TLS handshakeTransport Layer Security. The negotiation that establishes an encrypted channel over an existing TCP connection, including certificate verification and shared key derivation, which is what turns HTTP into HTTPS. costs further round trips, and only once it finishes does the HTTP request itself go out.
The request hits an entry point — often a load balancer — that determines which specific server instance should handle the work.
The server executes business logic: validating input, checking authentication, and performing calculations.
If the application requires stored data, it queries a database, waits for the result, and processes the record.
The application constructs a response (typically JSON or HTML) and sends it back through the stack to the client.
Key Terms
The Vocabulary of a Round Trip
Domain Name System. The distributed lookup system that translates human-readable domain names into the IP addresses machines actually use to route traffic.
Transmission Control Protocol. The SYN, SYN-ACK, ACK exchange that establishes a reliable, ordered connection between client and server before any application data is sent.
Transport Layer Security. The negotiation that establishes an encrypted channel over an existing TCP connection, including certificate verification and shared key derivation, which is what turns HTTP into HTTPS.
The property of a protocol or server where each request is handled independently, with no memory of prior requests, so any request can be served by any capable server.
One full cycle of a message sent and its reply received, the basic unit of network latency, since several handshake steps each cost a full round trip before useful data moves.
Reusing an already-established (and already-secured) TCP connection for multiple requests instead of tearing it down and renegotiating for each one.
Request / Response
Two Trips Through the Same Stack
Forward — request path
Return — response path
Worked Example
The Anatomy of a Request Path
Consider a user searching for a product on an e-commerce site. The lifecycle isn’t just a straight line — it is a series of transformations.
A shopper types "mechanical keyboard" into the search box and hits enter.
The load balancer inspects the request. If search traffic is under heavy load, it might route this one to a pool of "Search Services" optimized for read-heavy operations, rather than the "User Account" service.
The application server receives the request. It doesn't just pass the query directly to the database — it validates that the search string isn't malicious, checks if the user is authenticated, and verifies if the result is already available in memory.
If the database is hit, the request creates a "connection session." The database interprets the SQL/NoSQL command, optimizes the execution plan, and returns the rows.
Trade-offs
Limitations and Bottlenecks
A request is only as fast as its slowest component — often called the critical path. If the database is locked during a write operation, the application server hangs, which causes the load balancer to keep the connection open, which eventually leaves the user staring at a loading spinner.
Seen In The Wild
Products Built To Shorten This Chain
Cloudflare and Google's public DNS resolvers (1.1.1.1 and 8.8.8.8) exist specifically to make the DNS resolution step of this lifecycle faster and more reliable than relying on a default ISP resolver.
Browsers implement HTTP/2 and HTTP/3 largely to reduce the cost of this lifecycle at scale, multiplexing many logical requests over one physical connection so a page with 80 assets doesn't pay 80 separate handshake costs.
TLS certificate authorities like Let's Encrypt automated what used to be a slow, manual, paid step in this lifecycle (getting a trusted certificate), which is a major reason HTTPS became the web default rather than the exception.
API gateways at companies like Stripe and Twilio terminate the TCP/TLS handshake at the edge, close to the client, specifically to shorten this lifecycle for API calls originating far from their origin servers.
Key Points
What To Carry Forward
A single request is really a chain: DNS, TCP handshake, TLS handshake, then HTTP request/response, each step a real round trip with real latency.
DNS caching and connection reuse (keep-alive, HTTP/2 multiplexing) exist specifically to avoid repeating expensive steps in this chain on every request.
HTTP is stateless by design, which is what makes it possible to route any request to any server, a prerequisite for horizontal scaling.
TLS adds security but also adds round trips, a real latency cost that shows up disproportionately on the first request to a new connection.
Physical distance and round-trip count are the two real drivers of network latency, which is why both CDNs (attack distance) and connection reuse (attack round trips) matter.
Common Mistakes
Where This Usually Goes Wrong
Treating 'the request' as a single instantaneous step instead of a chain of separate network operations, which hides where latency actually comes from.
Assuming HTTPS only adds encryption, when it also adds real latency from the TLS handshake, especially on the first connection before session resumption kicks in.
Designing a client that opens a brand-new connection per request instead of reusing connections, paying the full DNS+TCP+TLS cost repeatedly for no reason.
Forgetting that DNS has its own caching and TTL behavior, which means DNS changes (like pointing a domain at a new server) don't take effect everywhere instantly.
“I used to think ‘loading’ just meant the page was being lazy. Turns out it’s four different systems passing notes before anyone says anything useful.”
Try It Yourself
Watch The Chain In Your Own Browser
Summary
The Map Before the Scale
Quiz Review
Check your understanding
Question 1 of 13
Why does connection reuse matter so much for a system serving many small API requests?
- ✓Each new TCP connection costs a round trip, and each new TLS connection costs one or two more, before any actual data moves. If a client opens a new connection per request, it pays that fixed handshake cost every time, which can dwarf the cost of the actual request. Reusing connections (via keep-alive or HTTP/2 multiplexing) amortizes that cost across many requests instead.