What Happens When You Open a Link

The problem: a name, and a page in under a second

You type shop.com/shoes and press Enter. In under a second the page is on your screen, pictures and all. Behind that second, several parts worked in turn: one turned the name into an address, one ran the shop's code, one looked up the shoes, and your browser put the page together.

"What happens when you type a URL?" is a classic interview warm-up, and it's the base of every system design answer: each design you draw later is this same trip with more parts.

How it works, step by step

1. The name becomes an address (DNS)

The internet delivers messages to numbered addresses (IP addresses), not to names. So your browser first asks DNS, the Domain Name System, to turn shop.com into an address such as 203.0.113.7 (an example address).

Your computer checks whether it saved the answer recently. If not, it asks a DNS resolver, usually run by your internet provider or a public DNS service; if that hasn't saved it either, it asks a root server, then the servers for .com, then the shop's own name servers. The answer comes with a TTL (time to live): how many seconds it may be kept. Every cache along the way saves it until then, so most lookups are answered close by.

A cache with a TTL of 300 seconds, over four visits:

time    you open          saved answer             asks DNS?
0 s     shop.com/shoes    none                     yes, kept until 300 s
60 s    shop.com/cart     shop.com, until 300 s    no
200 s   news.org/today    none for news.org        yes, kept until 500 s
400 s   shop.com/shoes    ran out at 300 s         yes, again

2. The connection and the request

With the address, the browser opens a connection to the server. For an https address it also sets up encryption, so nobody in between can read or change the messages (a later lesson covers how). Then it sends an HTTP request, a few lines of text:

GET /shoes HTTP/1.1
Host: shop.com
Accept: text/html

The first line names the method (GET, "send me this") and the page. The Host line names the site, because one server address often answers for many sites.

3. The server does the work

The server runs the shop's code for /shoes. The shoes and their prices live in a database, so the code asks it which shoes are in stock, then fills them into an HTML page. Your browser never talks to the database; only the server does.

These are the three parts every design diagram starts with: the client (the browser, the part that asks), a service (the server running your code) and a database (where the data is kept). An arrow shows who asks whom, and each answer comes back along it.

4. The response

The server answers with an HTTP response: a status line, a few headers, then the body.

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

<html> …the shoes page… </html>

The status code says how it went. Codes in the 200s mean it worked. Codes in the 400s mean the request asked for something wrong: 404 Not Found for /shoez, a page that doesn't exist. Codes in the 500s mean the server itself failed. Answering a missing page with 200 and a "not found" message is a common mistake: search engines and other programs trust the status, not the words on the page.

5. The page's other files

The HTML names the other files the page needs, and the browser asks for each one:

<link rel="stylesheet" href="/shop.css">    request 2
<script src="/shop.js"></script>           request 3
<img src="/red.jpg">                       request 4
<img src="/blue.jpg">                      request 5
<img src="/green.jpg">                     request 6
<img src="/black.jpg">                     request 7

With the HTML itself, this small page takes 7 requests; real shop and news pages often make dozens. They reuse the saved DNS answer and the open connection, and browsers ask for several at once, but the server answers every one.

Where the time goes

Most of the wait is distance. Say the server is on another continent, where one round trip, there and back, takes about 150 ms. Opening the page takes about four:

round trip 1   connect                     150 ms
round trip 2   set up encryption (https)   150 ms
round trip 3   ask for the HTML            150 ms
round trip 4   ask for the files           150 ms
               travel in all             ≈ 600 ms

Add the DNS lookup and the server's work and the page arrives in under a second. Inside one data center a round trip is about 0.5 ms, so the same four trips would take about 2 ms, 300 times less. That's why the server's call to its database barely shows next to the trips across the ocean, and why every extra trip on the busy path costs real time.

Choices and trade-offs

• A short or a long DNS TTL. A short TTL (a few minutes) lets you move a site to a new server quickly, at the cost of more lookups. A long one (a day, 86,400 seconds) saves lookups but can leave people on the old address for up to a day after a move.
• Fewer files or many. Every file is a request. Bundling scripts and styles cuts the count.
• The right status code. Callers act on it: a 404 says the thing isn't there, a 500 that the server failed and a later try might work. A wrong code makes every caller guess.

Where it shows up in design interviews

Every system design answer is this trip with more parts. A URL shortener, a chat app and a video site all start with a client sending a request to a service that reads or writes a database. Later lessons add the parts that make it scale: more servers behind a load balancer, caches, copies of files near users (CDNs), queues.

The habit interviewers look for is finding the busy path: the request most users make, most often. In a shop, shoppers might open shoe pages about 1,000 times a second (about 86 million a day) while staff add a new shoe a few times a day. The shoppers' path is the one to make fast.

Common interview questions

What happens when you type a URL and press Enter?

The browser looks up the name's IP address with DNS, often from a cache, then connects to that address and sends an HTTP request. The server runs its code, maybe reads a database, and sends back a status code and the HTML. The browser then requests the files the HTML names and draws the page.

Why is the second visit to a site faster?

The DNS answer is still saved, so there's no lookup until its TTL runs out. The browser may also reuse the open connection and its saved copies of images, scripts and styles.

What's the difference between a 404 and a 500?

A 404 means the request asked for something that doesn't exist: the problem is on the asking side. A 500 means the server failed while answering, and the same request might work later.

Why does one page make so many requests?

The HTML only names the stylesheets, scripts and images the page needs, and each is a request of its own. One stylesheet, one script and four pictures make 7 requests with the HTML; real pages often make dozens.

Summary

• DNS turns the name into an IP address; answers are saved for their TTL.
• The browser connects and sends an HTTP request: a method, a path, the site's name.
• The server runs the code and may ask a database.
• The response carries a status code (200, 404, 500…) and the HTML.
• The browser then requests every file the HTML names.
• A round trip costs about 150 ms across an ocean, 0.5 ms inside a data center.
• Every design is this trip with more parts: find the busy path and make it fast.