Module 01 · Lesson 2 of 14Free

Request lifecycle: what happens when you open a website

Level

Beginner

Topic

System design fundamentals

Reading time

15 min

Asha opens a product page on Kartly from her phone. In this lesson’s example, the application takes 95 ms, but the product text appears after 400 ms.

Where did the rest of that time go? We’ll follow one request from the address bar to the screen.

Kartly is still at its one-server stage: one app server with eight CPU cores and one PostgreSQL database. The public entry point below is a forwarding role, not a second app server.

We’ll trace HTTPS over TCP. Other transports come later; first, we need a clear path to follow.

Find the address before connecting

Asha enters https://kartly.example/products/482.

For our request, https selects secure communication. kartly.example identifies the host. /products/482 identifies the product resource.

DNS, the Domain Name System, finds an IP address for the hostname. A cached answer can avoid a remote lookup. Otherwise, the browser’s lookup reaches a DNS resolver, a service that obtains the answer. DNS resolves the hostname, not the product path.^{1Populating the page: how browsers workMDN contributors, MDN Web Docs, 2026}

Assume Kartly’s answer is 203.0.113.10. This documentation address represents its public entry point, not its database.

Our scenario assigns 40 ms to the lookup. That is an illustrative duration, not a normal value for every phone.

Notice the boundary: knowing an address does not prove anything is listening there. If someone gives you a building’s address, the building can still be closed.

Asha now knows where to connect. She has not requested the product yet.

Establish a protected conversation

TCP establishes a connection through three messages: SYN, SYN-ACK and ACK. TLS then authenticates the server and establishes encryption before the HTTP request. These are connection setup steps, not product-page work.^{1Populating the page: how browsers workMDN contributors, MDN Web Docs, 2026}

Think of the different questions they answer:

• DNS: where should the phone connect?
• TCP: can these endpoints establish a connection?
• TLS: can the phone establish a protected conversation with the intended server?

For this scenario, assign 60 ms to TCP setup. Assign another 60 ms to TLS setup. These are budget assumptions, not universal handshake timings.

Suppose the public entry point is reachable, but its certificate is invalid. Our expected outcome is a browser security warning. Making the product query faster would not help: application code has not run.

We choose to stop at that warning rather than bypass verification. A product page that loads through an untrusted connection would defeat the protection HTTPS is meant to provide.

Connection setup is now complete. Only now does the browser ask for the product.

The request reaches application code

HTTP carries the request and response. Here is a readable HTTP/1.1 example; headers carry information about the message, and the path identifies the requested resource.^{1Populating the page: how browsers workMDN contributors, MDN Web Docs, 2026}

GET /products/482 HTTP/1.1
Host: kartly.example
Accept: text/html

At Kartly’s public entry point, a reverse proxy forwards requests to the application. A load balancer uses this forwarding role to distribute requests across available app servers. NGINX supports forwarding to a single destination or a server group.^{2Module ngx_http_proxy_moduleNGINX, NGINX documentation, 2026}

Kartly currently has only one app server, so there is no distribution choice. For our example, the entry point also handles the phone’s TLS connection.

The distinction matters: the phone’s connection ends at the entry point. Forwarding to the app is another network hop. Encryption on that internal hop is a separate configuration choice.

Here is the request lifecycle inside this scenario:

1. The entry point forwards the product request to the app.
2. The app selects the handler for /products/482.
3. The handler asks PostgreSQL for product 482.
4. PostgreSQL returns the stored product fields.
5. The app asks the pricing service for the current price.
6. The app combines those results into HTML.
7. The entry point forwards the response to the phone.

The pricing service is an existing dependency in Kartly’s example world. We are not introducing a new service to solve this request.

Each component has a boundary

This is the responsibility map for our design:

This page is a read path. Opening it does not create an order or change stock. That keeps a failed page load separate from a failed purchase.

The server has assembled a response, but the customer still needs something visible.

A response is not a screen

Our application returns HTML through the entry point:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!doctype html>
<html lang="en">
<head><title>Desk lamp</title></head>
<body><h1>Desk lamp</h1><p>₹799</p></body>
</html>

Rendering turns downloaded content into visible pixels. The browser parses HTML, applies styles, calculates positions and paints. Images, stylesheets and scripts can require further requests; parsing can begin before the complete HTML arrives.^{1Populating the page: how browsers workMDN contributors, MDN Web Docs, 2026}

For our calculation, the small HTML response contains everything needed to show the initial product text. A product photograph can appear later. This assumption keeps “text visible” separate from “every resource finished”.

Imagine two versions of Kartly:

• Version A returns the product text in HTML.
• Version B returns an empty page, then requires JavaScript to fetch the product.

In version B, our product fetch becomes another dependency before text can appear. That may suit an application with complex client-side behaviour, but it adds work to this particular path.

A successful HTML response therefore proves less than a successful customer experience. We need to account for the whole path.

Account for the missing milliseconds

These numbers are an illustrative budget for Asha’s first visit. They are not measured production statistics.

The application’s 95 ms follows Kartly’s established example: 5 ms of CPU work, 40 ms waiting for PostgreSQL and 50 ms waiting for pricing.

Do not add those dependency waits again. They are already inside application time.

Now suppose you halve application time. Under these assumptions, you save about 48 ms—not half the page-load time.

That calculation tells you where further investigation belongs. It also raises another question: must every visit pay every cost?

The next request can skip work

Caching means retaining a result for reuse. Connection reuse means retaining the conversation itself. They save different work: a cached address avoids lookup, while an existing connection avoids setup. curl also reuses connections across transfers within one invocation.^{1Populating the page: how browsers workMDN contributors, MDN Web Docs, 2026}

For our second request, assume the connection is still usable. Keep every other budget item unchanged.

That removes 160 ms of setup from the example. Initial text would appear after 240 ms. The product still comes from the application.

A different optimization is to reuse a stored response. For Kartly, that creates a product question: how old may the displayed price be?

Cache placement develops response caching. For now, keep the two questions separate: “Can we reuse the connection?” and “Can we reuse the answer?”

Find the last successful boundary

Use the following as a diagnosis exercise for our design. Symptoms are possible outcomes, not exact browser messages or universal status-code mappings.

A proxy can enforce connection and read timeouts. NGINX documents these separately; its read timeout measures gaps between reads, not a total request deadline.^{2Module ngx_http_proxy_moduleNGINX, NGINX documentation, 2026}

For Kartly, choose an explicit failure response when current pricing is unavailable. Do not silently invent a price. A message such as “Price temporarily unavailable” lets Asha distinguish missing information from an actual offer.

The useful investigation question is not “Did the website fail?” It is “What was the last completed step?”

Try it yourself

Run this against a public example site, not Kartly’s fictional domain. In Windows PowerShell, use curl.exe instead of curl.

curl --http1.1 -sS -o timing-page.html -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/

Illustrative output:

dns=0.040 tcp=0.100 tls=0.160 first=0.316 total=0.340

These are cumulative seconds from the start. Subtract adjacent values: TCP adds 60 ms here. The interval after TLS includes request travel, server work and response travel—not server work alone. curl downloads the response but does not render a browser page.^{3curl - How To Usecurl contributors, curl documentation, 2026}

Your results will differ. A configured proxy can also change what the connection timings represent.

Where this shows up

• Design: a URL shortener on a single server: separates request handling from the stored lookup.
• Design: a fast product catalog page: decides which answers can avoid the original request path.

One request is now accounted for; next, Server concurrency explains what happens when many arrive together.

Common mistakes

• Timing only the handler. Our 95 ms measurement excludes setup, travel and rendering.
• Treating DNS as a product lookup. Its answer gets the phone to an entry point, not to a database row.
• Treating reuse as freshness. An existing connection says nothing about whether a stored price is current.
• Adding nested times twice. Database time is already included when the application measurement surrounds that call.

Check your understanding

Summary