Lesson 04: What Really Happens When You Click a Button? DNS, TCP, TLS & HTTP Explained

System Design Interview Preparation: Understand DNS Resolution, TCP Handshakes, TLS Encryption, HTTP Requests, Server Responses, and Why Network Latency Makes Applications Slow.

Tagline: Your Code Isn't the Whole Story. The Network Matters.

One tap, and a page loads two seconds later. In those two seconds, your request crossed many systems. Each one adds delay. Each one can fail. If you cannot name them, you cannot say why a page is slow.

The problem at Varastra

Varastra is an online store for Indian ethnic wear. It sells sarees, kurtas and lehengas. Omar, a customer in London, taps "Buy" on a kurta. The page takes three seconds.

Ana, an engineer at Varastra, looks at the code. It is fast. The database is fast. Yet Omar waits.

Kofi, a senior engineer, asks her a question: "What happens before your code even runs?" Ana realizes she has never listed the steps. She starts with the diagram.

The diagram at a glance

The diagram shows the TCP three-way handshake between a client and a server. It marks that the client must wait for message 2 before it can go on. That wait is one round trip.

It then compares two users with the same page and the same code:

The round-trip times are made up. Only the distance changed. TLS steps are not counted in the diagram.

The path, one step at a time

1. DNS. Omar's phone knows the name varastra.example. It needs a number address. The Domain Name System (DNS) turns names into addresses.

Systems that look up names keep the answers for a while. Each record carries a value called TTL (time to live). RFC 1034 says the TTL "describes how long a RR can be cached before it should be discarded." (RR means resource record.) If Varastra changes servers, some users keep the old address until the TTL ends.

2. TCP. The phone opens a connection to that address. RFC 9293 calls the opening procedure the "three-way handshake." One side says hello, the other answers, and the first confirms. This takes time, because a message must travel out and back before data can flow. That cost is reasoning from the handshake, not a number from the RFC.

3. TLS. TLS makes the connection private. It is the "S" in HTTPS. TLS 1.3 is defined in RFC 9846 (July 2026), which replaces the older RFC 8446.

TLS 1.3 also has an early-data mode called 0-RTT. The standard says its security is weaker than for other TLS data, and that "there are no guarantees of non-replay between connections." So the same request could be sent again by someone else. A "pay now" call should not depend on early data alone. That last point is advice, not a rule from the RFC.

4. HTTP. Now the real request is sent. RFC 9110 defines HTTP as a stateless protocol: each request's meaning can be understood on its own. A server cannot assume it knows who you are from the last request. Every request must carry what the server needs, such as a login token.

5. Inside Varastra. The request reaches a load balancer. It picks a server copy. The service reads or writes the database. Then the answer travels back the same way.

The same page, two distances

Here is the diagram's arithmetic as code.

# Time to load one page = one round trip to connect + one round trip for the request.
# TLS steps are not counted. Round-trip times are made up.
def page_time_ms(rtt_ms):
    connect = rtt_ms      # TCP handshake: wait for the server's reply
    request = rtt_ms      # send request, wait for the response
    return connect + request

for name, rtt in (("Far user", 150), ("Near user", 10)):
    print(f"{name}: round trip {rtt} ms -> {page_time_ms(rtt)} ms")

Output:

Far user: round trip 150 ms -> 300 ms
Near user: round trip 10 ms -> 20 ms

The same code costs the far user 15 times more waiting. It is not the code. It is the distance.

What this suggests

These are ideas from the reasoning above, not tested results.

• Keep content near users, for example with a CDN.
• Reuse open connections.
• Make fewer round trips.
• Do slow work later, outside the customer's wait.

Takeaways

1. A request passes through DNS, TCP, TLS and HTTP before your code runs.
2. Every hop adds delay and a chance to fail.
3. Distance multiplies every round trip.
4. TLS early data (0-RTT) can be replayed, so keep sensitive actions out of it.