Tracing a Web Request: From DNS to Database

Hello again. You now have the pieces needed to follow a request beyond the browser: HTTP defines the request and response, TCP provides a reliable connection in the common web case, and HTTPS adds TLS protection before HTTP data is exchanged.

This lesson puts those pieces together. We will trace a typical dynamic request from a browser through DNS resolution and Internet routing to a web application and its database, then follow the response back. The goal is not to memorize every protocol detail, but to develop a dependable mental model you can explain during a system-design interview.

---

Start with one concrete request

Assume a user enters this URL:

https://shop.example.com/products/42

The browser needs to answer several different questions:

Question	Example answer	System component involved
What service does this name refer to?	An IP address for shop.example.com	DNS
How can data reach that IP address?	Packets are forwarded across networks	Routers and IP networking
Which process should receive it?	The HTTPS service listening on port 443	TCP and sockets
Is the connection private and authentic?	Yes, after a TLS handshake	HTTPS/TLS
What should happen for /products/42?	Retrieve product 42 and return a page or JSON	Web application
Where is the product’s persistent data?	A database	Database server

A useful correction to a common misconception: the hostname does not necessarily resolve directly to the machine running application code. In a production system, DNS often returns the address of a public entry point, such as a CDN, reverse proxy, or load balancer. For this lesson, that entry point will ultimately deliver the dynamic request to an application server.

MDN’s How the web works gives a compact foundation for the first half of the journey: name resolution, HTTP communication, and packet transport.

---

1. DNS turns a name into a reachable address

Humans use shop.example.com; the Internet forwards traffic using IP addresses. DNS, the Domain Name System, maps names to IP addresses.

The browser first checks whether it already knows the answer. In practice, several caches may be consulted:

1. The browser’s DNS cache.
2. The operating system’s DNS cache.
3. A configured DNS resolver, often run by an ISP, enterprise, or public DNS provider.

If a cache has a still-valid answer, the browser can use it immediately. If not, the resolver performs the necessary DNS lookup through the DNS hierarchy until it finds an authoritative answer for the domain. It then returns an IP address and usually caches it for a limited period specified by the DNS record’s time to live, or TTL.

For example, the result might conceptually be:

shop.example.com  =  203.0.113.10

That address is illustrative. A real DNS answer may contain several addresses for redundancy, may direct different regions to different infrastructure, or may point to a CDN rather than an origin application server.

The important separation is:

• DNS resolution answers, “What IP address should I contact?”
• Network routing answers, “How do packets get from my network to that address?”

DNS is often visible in system design because it is a first dependency in the request path. If DNS is slow or unavailable and clients have no usable cached answer, they cannot even begin connecting to the service.

The following short segment is a good visual pass through the browser-side portion of the trace.

---

2. Packets travel through the network

Once the browser has an IP address, it can communicate with that destination. In the usual HTTPS case discussed in earlier lessons, it opens a TCP connection to port $443$.

The browser’s device does not need to know the complete physical path to the destination. It sends packets to its local network gateway. From there, routers in successive networks examine each packet’s destination IP address and choose an appropriate next hop based on their routing tables.

At a high level, each router does three things:

1. Receives a packet from one network link.
2. Reads enough of its network header to identify the destination IP address.
3. Forwards the packet toward a next network that it believes can get closer to that destination.

This continues across networks until packets reach the public endpoint associated with the server’s IP address. The physical path may involve a home or office router, an ISP, Internet backbone networks, and the provider hosting the service.

Two details matter when explaining this in interviews:

• A router forwards packets, not an abstract HTTP request. HTTP data is carried inside transport-layer segments, which are carried inside IP packets.
• The request and response are logically part of one client-server exchange, but their packets are not guaranteed to travel through exactly the same intermediate routers in both directions.

TCP handles many complications that arise beneath HTTP: packets can be lost, duplicated, delayed, or arrive out of order. TCP uses sequence information and acknowledgements to present the application with a reliable ordered byte stream. The application server therefore receives a coherent HTTP request rather than manually reassembling raw network packets.

For a newly opened HTTPS connection, the broad order is:

1. Establish the TCP connection with the server’s public IP address and port $443$.
2. Perform the TLS handshake.
3. Send encrypted HTTP request data through the established connection.

If the browser can reuse an existing secure connection, it may avoid some of this setup cost. Likewise, DNS caching may avoid a fresh DNS lookup. When people say “what happens when I type a URL,” they usually mean the full cold path; real browsers aggressively optimize that path through reuse and caching.

---

3. The public web server receives the request

After TLS is established, the browser can send an HTTP request such as:

GET /products/42 HTTP/1.1
Host: shop.example.com
Accept: text/html

At the public-facing side, some server component accepts the request. In a small deployment, this might be the same machine and program that runs the application. In a larger deployment, a web server or reverse proxy commonly accepts public traffic and passes dynamic requests to one of several application instances.

At this point, the request must be classified:

• A request for a static resource, such as /assets/site.css or /images/logo.png, can often be served directly from files or a cache.
• A request for a dynamic resource, such as /products/42, needs application code to compute a response using current data and business rules.

The supplied MDN diagram depicts this distinction.

Notice the diagram’s boundary: the browser is on the client side, while the web server, web application, files, and database are server-side components. The diagram is intentionally simplified, but it captures a durable architectural idea: not every request reaches the database. Static content may be returned without application code, and an application may sometimes return cached data. For a dynamic, uncached request, however, the database is commonly part of the critical path.

Read MDN’s explanation of a dynamic site to connect the diagram to the server-side responsibilities.

---

4. The application server turns an HTTP request into work

An application server runs the server-side program that implements the product’s behavior. With Java experience, it is reasonable to picture a Java web service receiving the request, matching it to a handler, and invoking domain logic. The system-design level is more important than the framework details.

For GET /products/42, application work often includes:

1. Route the request. Match the method and path to the product handler.
2. Interpret request data. Extract the product identifier, headers, cookies, or query parameters as needed.
3. Authenticate and authorize if required. A public product page might require neither; an account page generally would.
4. Apply business rules. For example, decide whether product 42 is visible, discontinued, or region-restricted.
5. Read or update persistent data. Query the database or, in later designs, perhaps first consult a cache.
6. Construct the response. Return HTML for a browser page, or JSON for a frontend application or mobile client.

The application does not generally read a database “file” directly. It communicates with a database server using that database’s protocol and a database connection. The database executes the query, locates the relevant stored records, and returns a result set.

A conceptual SQL query might be:

SELECT id, name, price, availability
FROM products
WHERE id = 42;

The application then turns the result into an HTTP response. A browser-oriented server-rendered response might look like:

HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <body>
    <h1>Wireless Keyboard</h1>
    <p>Price: $49.99</p>
  </body>
</html>

An API-oriented response might instead be JSON:

HTTP/1.1 200 OK
Content-Type: application/json

{"id":42,"name":"Wireless Keyboard","price":49.99}

Both are ordinary HTTP responses. What differs is the representation the client expects.

A database is a separate dependency

In a development environment, application and database might run on the same laptop. In production, they are usually separate processes and often separate machines or managed services. The application therefore makes another network call on the request’s behalf.

That has immediate consequences:

• If the database is slow, the application response may be slow.
• If the database is unavailable, the application may return an error even though the application server itself is healthy.
• A database query is often a major contributor to end-to-end request latency.

This is why a system-design diagram should show the database explicitly rather than treating it as an invisible implementation detail.

---

5. Trace the full request and response

Here is the complete cold-path trace for our example. Treat it as a narrative template, not as a claim that every production system has exactly these components.

1. The user enters https://shop.example.com/products/42 in the browser.

2. The browser parses the URL. It identifies HTTPS as the scheme, shop.example.com as the hostname, and /products/42 as the requested path.

3. The browser looks up shop.example.com in available DNS caches. If necessary, a DNS resolver finds an IP address for the service’s public endpoint.

4. The browser sends packets toward that IP address. Routers forward the packets across networks based on their destination IP address.

5. The browser establishes a transport connection to the destination service, conventionally TCP port $443$ for HTTPS. It performs a TLS handshake when a new secure connection is needed.

6. The browser sends the encrypted HTTP GET /products/42 request.

7. The public web server receives and decrypts the request at the TLS termination point. It recognizes that this is a dynamic product request and forwards it to an application server.

8. The application server runs the product handler. It validates the request, applies product rules, and queries the database for product 42.

9. The database executes the query and returns the requested product data to the application server.

10. The application generates an HTML or JSON representation, assigns a status such as 200 OK, and returns an HTTP response to the web server.

11. The response travels back across the established connection to the browser. Network packets traverse routers back toward the client, potentially along a different physical route.

12. The browser receives the response, verifies and decrypts its TLS-protected contents, then renders HTML or lets frontend JavaScript process JSON. It may initiate additional requests for CSS, JavaScript, images, fonts, and other referenced resources.

The last step explains why loading “one web page” is often many HTTP requests. The initial HTML may reference a stylesheet, several scripts, product images, and analytics resources. Each can have its own caching and delivery path. Later in the course, CDNs and multi-layer caches will reduce the load and latency of these repeated asset requests.

---

How to communicate this in a system-design interview

For an entry-level interview, a concise explanation is more valuable than an exhaustive tour of Internet protocols. A strong baseline answer would be:

The client resolves the service hostname through DNS, usually using caches when available. It opens a secure connection to the public endpoint and sends an HTTPS request. Internet routers forward the underlying IP packets to that endpoint. A web server receives the request; static files may be served directly, while dynamic requests are routed to application code. The application applies business logic, reads or writes the database, creates an HTTP response, and sends it back to the client over the secure connection.

Then make the architecture-specific details explicit:

• Does DNS point to one server, a load balancer, or a CDN?
• Is the response static, cached, or dynamically generated?
• Does the application need the database for this operation?
• Where does TLS terminate?
• Which dependency is likely to dominate user-visible latency?

That last question leads naturally to the next lesson. Each stage has a cost: DNS lookup, connection setup, network travel, application processing, and database access. A system designer needs vocabulary to discuss those costs accurately.

---

Key takeaways

• DNS maps a human-readable hostname to one or more IP addresses, usually with caching at several layers.
• Network routing forwards IP packets through routers toward the destination IP address. It is distinct from DNS resolution.
• For a new HTTPS connection, the browser typically establishes TCP, completes TLS, and only then sends encrypted HTTP data.
• A public web server can return static files directly or forward dynamic requests to an application server.
• The application server interprets the HTTP request, applies business rules, communicates with the database, and constructs the HTTP response.
• The database is often a separate network dependency and can be a major source of latency or failure.
• A browser page load commonly causes additional requests for resources referenced by the initial response.

Next, you will distinguish latency, throughput, bandwidth, and concurrency. Those terms let you reason quantitatively about why the request path you traced here feels fast or slow under real traffic.