Everyday storyVisiting a friend's new flat
Your friend Priya has just moved to Green Park Society, but you don't know her flat number. At the gate you ask the guard, "Which flat is Priya's?" He checks his register: "C-402." You go up, ring the bell and ask, "Can I borrow your charger?" She hands it over, or says, "Sorry, it's broken."
You did three things: turned a name into an address, made a request, and got a response. Notice a few more details, because each one turns up on the internet too. You don't ask the guard every time you visit; after the first trip you remember "C-402" for a while. If Priya moves flats, your memory is now wrong until you ask again. And if you want to hand over something private, you don't shout it across the courtyard; you wait until the door is shut.
Opening a website works in exactly this shape. Your browser asks an address book where the website lives, remembers the answer for a while, knocks on the right door, has a private conversation, and walks away with what it asked for. The whole visit just happens a few hundred times faster than climbing four floors.
In a real productOpening a shopping site on your phone or laptop
You type a shop's name into the browser, or tap a link in a WhatsApp message about a Diwali sale, and in about a second the page appears. Behind that second, your phone asked where the shop's computer is, opened a private line to it, asked for the page, and then fetched dozens of photos and other files to draw it. A small padlock next to the address tells you the line was private.
You also notice when this goes wrong. "This site can't be reached" means the address couldn't be found. "404 Not Found" means the shop's computer answered, but has no such page. "500 Internal Server Error" or "Something went wrong" means the shop's computer itself had a problem. And on a sale night, a page that usually opens instantly might spin for ten seconds. By the end of this lesson you'll know which step each of those messages comes from.
The ideaHow it works
Two computers, one conversation
Opening any website is a short conversation between two computers: yours, called the , and the website's, called the . The client asks; the server answers. Your phone is a client, and so is the app on it. The server is a computer kept in a large building full of computers, a , switched on all day and night, waiting for questions.
What you type is a , a full web address such as https://shop.example/diwali. It has three parts that matter here:
- https says how to talk: the language, and that the line should be private.
- shop.example is the : which website.
- /diwali is the path: which page on that website.
Everything that follows happens in four steps: find the server, open a line, ask and answer, then fetch the rest of the page.
Step 1: find the server
Computers find each other by number, an such as 203.0.113.7, not by name. Names are for people. So your browser first asks , the internet's address book (the guard with the register): "Where does shop.example live?"
Your phone doesn't search the whole internet itself. It asks a , usually run by your mobile or broadband company. If the resolver doesn't already know the answer, it works it out in a few hops, starting from the end of the name:
- It asks the root servers, which know who looks after each ending (.com, .in, .example): "Who runs .example names?"
- It asks the .example servers: "Who runs shop.example?"
- It asks the shop's own DNS server: "What's the address?" The answer: 203.0.113.7.
That could take a tenth of a second or more. So every answer comes with a "remember me for" time, called a , often a few minutes to a day. Your phone, your browser and the resolver all keep a copy until it runs out. Keeping copies of answers to reuse is called a , and it's one of the most important ideas in this whole course. Thanks to caching, most lookups take a few milliseconds or nothing at all, because somebody (often you, earlier) asked the same question recently.
Step 2: open a line
Now your phone knows where the server is, but it can't just shout the request into the void. Messages on the internet travel as small numbered pieces called , and a piece can get lost or arrive out of order. So the two computers first set up a reliable line using , which numbers every piece, puts them back in order and resends any that go missing.
Setting up that line takes a quick exchange of greetings, a : "Hello, can we talk?" "Yes, go ahead." That's one , there and back.
Then comes the lock. Almost every site today uses , so the two sides agree on a secret key that scrambles everything they send. Anyone in between (the café Wi-Fi, the network company) sees only gibberish. Your browser also checks the site's certificate, a kind of ID card, to make sure it's really talking to shop.example and not an impostor. That takes about one more round trip. When it's done, you see the padlock.
Step 3: ask and answer
Now the real conversation begins. Your browser sends a using , the language browsers and servers share. A request has three parts:
- An , the kind of request. GET means "please send me this"; POST means "here's something for you", like a form or an order.
- The path, such as /diwali.
- A few , short notes on the envelope: which browser you use, which language you prefer, and often a , a small token the site gave you earlier so it remembers your cart or that you're signed in.
The server works out the answer, perhaps checking a database for today's offers, and sends a . It starts with a , a three-digit number saying how it went. The first digit tells you the family:
- 2xx, it worked. 200 means OK, here it is.
- 3xx, look elsewhere. 301 means "this page has moved to a new address", and the browser follows it automatically, a .
- 4xx, the request was the problem. 404 means no such page; 403 means you're not allowed.
- 5xx, the server was the problem. 500 means something broke inside; 503 means "too busy, try later".
After the code come the response's own headers (for example, "you may keep this photo for a day") and then the body: the page itself.
- 1
Your browserDNS
Where does shop.example live?
- 2
DNSYour browser
At 203.0.113.7
- 3
Your browserWebsite's server
Please send the home page (an HTTP request)
- 4
Website's serverYour browser
200 OK, here it is (an HTTP response)
Step 4: one page, many requests
Here's the surprise for most people. The first response isn't the whole page. It's an file: the words, headings and links, plus a list of every other file needed to draw it. Your browser reads that list and sends more requests, for photos, a style file that sets the colours and fonts, and scripts that make buttons work. A typical shopping page needs 40 to 100 requests for a single tap.
Those extra files are the same for every shopper, so sites rarely send them all from their own server. They keep copies on a , a network of servers spread across many cities, so a shopper in Pune gets the photos from a computer in Mumbai rather than one on another continent. Only the parts that are different for you, like your cart or your name, need to come from the shop's own server. Browsers also reuse an open line for many requests in a row, so they pay for the hello and the lock once, not 40 times.
Adding up the wait
Every step takes time, and the total wait from tap to page is called . A big part of it is simple distance. Signals in a fibre-optic cable travel at about two-thirds of the speed of light: fast, but India to America and back still takes about a quarter of a second.
Suppose the shop's server is in Mumbai and you're in Pune, about 20 ms (milliseconds, thousandths of a second) there and back on a good connection:
- Look up the address: 0 ms if remembered, about 20 to 40 ms if not.
- Say hello: one round trip, 20 ms.
- Lock the line: one more, 20 ms.
- Send the request and get the first piece of the answer: 20 ms, plus however long the server takes to think, say 100 ms.
That's about 200 ms before the first word of the page arrives. Then come the photos and scripts. A well-built site shows readable text in under a second and is fully drawn in one to two. A site that ignores these numbers can easily take five.
Most of system design is about keeping that wait short while lakhs of people ask at the same time, and it's measured carefully. Engineers don't just look at the average wait; they look at the , the time that 99 out of every 100 requests beat. If the p99 is 3 seconds, one shopper in a hundred is waiting at least 3 seconds, and at a lakh visits a day that's a thousand annoyed people.
The big idea: every app and website you use is built on this one loop: find the server, open a line, send a request, get a response, and repeat it for every file the page needs.
For experienced engineers
The full path: the stub resolver on the device checks the OS cache, then queries a recursive resolver, which walks root, TLD and authoritative servers (iteratively, caching each referral with its own TTL; negative answers are cached too). TCP's three-way handshake costs one RTT before data; TLS 1.3 adds one more (TLS 1.2 needed two), and session resumption with 0-RTT can send data in the first flight at the cost of replay risk for non-idempotent requests. HTTP/2 multiplexes many requests over one connection, removing per-request connection cost but still suffering TCP head-of-line blocking when a packet is lost; HTTP/3 runs over QUIC on UDP, merges the transport and TLS handshakes into one RTT and isolates loss per stream, which helps on lossy mobile networks. Browsers add preconnect, DNS prefetch and connection pooling (typically keyed by origin) to hide setup. TTFB is DNS + connect + TLS + request transit + server time; the user-facing metrics (first contentful paint, largest contentful paint) also include render-blocking CSS and scripts. Low DNS TTLs speed up failover but raise resolver load and lookup misses; some resolvers clamp very low TTLs, so cutovers are never perfectly instant.
Step by stepAsha opens a Diwali sale, millisecond by millisecond
It's 8 pm on a Friday. Asha, in Pune, taps a link in her family WhatsApp group: https://shop.example/diwali. She's on 4G, and each round trip to Mumbai takes about 50 ms on her mobile network. Here's what her phone does.
-
0 ms, check memory. Her phone looks in its own DNS cache for shop.example. She hasn't visited this week, so there's nothing there.
-
0 to 40 ms, ask the resolver. Her phone asks her mobile company's DNS resolver. Someone else in Pune opened the same sale link a minute ago, so the resolver already has the answer in its cache: 203.0.113.7, with a TTL of 5 minutes. No need to ask the root servers.
-
40 to 90 ms, say hello. Her phone and the shop's server do the TCP handshake: one round trip.
-
90 to 140 ms, lock the line. They agree on a secret key, and her browser checks the certificate really belongs to shop.example: one more round trip. The padlock is ready.
-
140 ms, send the request. GET /diwali, with headers saying she's on an Android phone, prefers English, and carries a cookie from her last visit that holds her cart.
-
165 to 285 ms, the server thinks. The request arrives 25 ms later. The server spends about 120 ms finding today's offers and reading her cart from the database.
-
310 ms, the answer arrives. "200 OK", followed by a 60 KB HTML page. Her browser starts reading it at once.
-
330 ms, the rest of the page. The HTML lists 1 style file, 9 scripts and 30 product photos, about 2 MB in all. They live on a CDN server in Mumbai, much closer on the network. Her browser opens one line to it and asks for many files at a time.
-
About 600 ms, she can read it. The text, prices and "Buy now" buttons appear while the photos are still coming.
-
About 1.3 s, the page is complete. The last photo lands. One tap became 41 requests.
- 1
Asha's phoneDNS resolver
0 ms: where is shop.example?
- 2
DNS resolverAsha's phone
40 ms: at 203.0.113.7, good for 5 minutes
- 3
Asha's phoneShop's server
40 to 140 ms: say hello, then lock the line
- 4
Asha's phoneShop's server
140 ms: GET /diwali
- 5
Shop's serverAsha's phone
310 ms: 200 OK, and the HTML page
- 6
Asha's phoneNearby CDN
330 ms: please send 30 photos, styles and scripts
- 7
Nearby CDNAsha's phone
1.3 s: the last photo arrives, page complete
- Two minutes later, she comes back to compare a price. The DNS answer is still remembered, the line is often still open, and the photos are in her browser's cache because the CDN said "keep these for a day". Only the fresh HTML is fetched. The page appears in about 300 ms.
Notice where the time went. On the first visit, about 140 ms was setup (finding and connecting) and 120 ms was the server thinking. Most of the rest was photos. That's why sites remember everything they can, keep copies near users, and reuse open lines.
What happens when…Situations
Real situations this idea runs into, and how well-built systems handle each one.
What happens when you type the name wrong
You type shopexmaple instead of shop.example. Your phone asks the resolver, which asks the servers along the chain, and the final answer is "no such name". There's no address, so there's nobody to send a request to. The browser shows "This site can't be reached" or "Server not found". Nothing is wrong with the shop; your request never left the first step.
A nastier version: a typo that does exist, because someone registered it on purpose to look like a real shop and collect people's passwords.
Browsers suggest close matches and complete names from your history, so you rarely type the whole thing. Well-run businesses register common misspellings of their name and redirect them to the real site. And the padlock check helps here too: the certificate shows exactly which name you're connected to, so a look-alike site can't pretend to be the real one on a private line.
What happens when the server says 404 or 500
These two errors look similar but come from very different places. A 404 means the conversation went perfectly: the address was found, the line opened, the server understood the request and replied, "I don't have that page." Maybe the product was removed, or the link had a typo. A 500 means the server tried to answer and something broke inside it: a bug, or a database that didn't respond.
The difference matters to whoever has to fix it. A 404 is usually a broken link to update. A 500 is the shop's problem, and if lots of people are seeing it at once, someone should be woken up.
Good sites use the right code for each problem, because browsers, search engines and monitoring tools all read them. When a page moves, they send a 301 redirect to the new address instead of a 404, so old links keep working. They show a friendly error page with a search box and a link home. And they count every 5xx response, with an alarm that rings when the share goes above, say, 1 in 1,000.
What happens on public Wi-Fi at a café
You're at a café in Bengaluru, on its free Wi-Fi, and you sign in to a shopping site. Every packet you send passes through the café's router and then several network companies before reaching the shop. Without protection, anyone on that path could read your password or change the page on its way to you, for example swapping the bank account number on a payment page.
HTTPS scrambles everything with a key that only your browser and the real server know, so people in between see gibberish and can't change anything without it being detected. The certificate check makes sure the other end is genuinely the shop. That's why browsers now warn loudly on sites without the padlock, and why every serious site uses HTTPS on every page, not just the sign-in page.
What happens when lakhs of people open the same page at 8 pm
A sale starts at 8 pm and 2 lakh people tap the link within a minute. One server can only work on so many requests at once. The rest wait in line, and the line grows faster than it shrinks. Requests that wait too long hit a and fail, and people press refresh, which adds even more requests.
Big sites spread the crowd across many servers. A sits in front and hands each new request to whichever server is least busy, so three servers take about a third each, and more can be added before a big day. The photos and scripts are already served by the CDN, so the shop's own servers only build the personal parts of each page. Some sites even turn on a waiting room that lets people in a few thousand at a time.
What happens when a website moves to a new address
The shop moves its server to a new data centre, so shop.example now lives at a new IP address. The shop updates its DNS record. But resolvers and phones all over the country remember the old address until their TTL runs out. If the TTL was one day, some shoppers keep knocking on the old door for up to a day, and if the old server is switched off, they see errors.
Teams plan a move in advance. A day or two before, they shorten the TTL to a few minutes, so copies of the old answer expire quickly. They keep the old server running (or forwarding requests) until traffic to it falls to nearly nothing, and only then switch it off. Afterwards they raise the TTL again, so lookups are cached for longer and stay fast.
Watch outCommon mistakes
Putting the server on the other side of the world
A startup in Indore picks the cheapest hosting option it finds, in a data centre in America, though nearly all its customers are in India. Each round trip now takes about 250 ms instead of about 20. The hello, the lock and the request alone add up to three-quarters of a second, before the server has even started thinking, and photos crawl in after that. The server isn't busy at all; the pages are slow purely because of distance.
Host the server in a data centre close to most users, such as one in Mumbai, Chennai or Hyderabad, and serve photos and other shared files from a CDN with copies in many Indian cities. As a rule of thumb, every round trip you can't avoid should be a short one.
Making one page need a hundred separate files
A team adds a new script for every small feature and uploads full-size photos straight from a camera. The home page grows to 120 requests and 8 MB. On fast office Wi-Fi it seems fine. On a 4G phone in a moving train, it takes 15 seconds, and many visitors give up before it loads.
Count requests and bytes, and test on a slow phone connection, not just the office Wi-Fi. Combine small scripts, shrink photos to the size they're actually shown at, use for text files, and tell browsers to keep files that rarely change so return visits skip them.
Sending the wrong status code
A server hits an error but replies "200 OK" with a page that says "Oops, something went wrong". To a person it looks like an error. To the browser, search engines and the team's monitoring, it looks like a perfectly good page. The monitoring stays green while customers fail to check out for an hour, and a search engine may even list the error page as the product page.
Use status codes honestly: 200 only when it worked, 404 when something doesn't exist, 500 or 503 when the server failed or is overloaded. Machines read the number, not the words, and every alarm and dashboard depends on it.
Checking only the average wait
A team reports that its pages load in 400 ms on average, so everything looks great. But the average hides the slow tail: most pages take 300 ms, while one in fifty takes 6 seconds, often for people with the biggest carts or the slowest networks. Those are the customers who complain and leave.
Track the p95 and p99 as well as the average, and look at who lands in the slow tail. Set a target such as "p99 under 2 seconds" and alert when it's broken. The simulator below shows p99 for exactly this reason.
Interview angleIn an interview
"What happens when you type a URL into the browser and press Enter?" is one of the most common warm-up questions in software interviews. It sounds simple, which is the point: the interviewer wants to see how many layers you understand and whether you can explain them in order, clearly.
A strong answer covers:
- breaking the URL into its parts: how to talk, which site, which page;
- the DNS lookup, with caching at the browser, the device and the resolver, and the TTL that limits it;
- opening the connection (a TCP handshake) and the HTTPS lock with a certificate check;
- the HTTP request (method, path, headers, cookies) and the response (status code, headers, body);
- the HTML listing further files, fetched from a CDN over the same open line;
- a rough time budget, for example 20 ms round trips and about 200 ms to the first byte.
Follow-up: "Why doesn't every visit do a full DNS lookup?" Answers are cached at several layers for as long as their TTL allows, so most lookups are answered from memory in a millisecond or two.
Follow-up: "What changes with HTTPS?" The two sides agree on a secret key and the browser checks the site's certificate before any data is sent, which costs about one extra round trip but stops anyone in between from reading or changing the traffic.
Follow-up: "How would you make this page faster for users in India?" Put the server and a CDN close to them, reuse connections, send fewer and smaller files, and cache whatever doesn't change, because most of the wait is round trips and bytes, not the server's thinking time.
Try it in the simulator
Goal: Run the design and find the request's p99 latency in the metrics panel.
This is the smallest possible system: some users, one server and a database. It's Asha's visit without the CDN: every request goes to the shop's server, which asks its database. Press Run and watch requests travel along the arrows. The metrics panel shows how long they take. Then turn up the number of users and see what happens to the wait when the server gets busy.
Hint
Latency is shown as p99: 99 out of every 100 requests are at least that fast.
Quick checkCheck your understanding
Words in this lessonThe jargon, in plain English
Every technical word used above. In the lesson, tap any word with an ⓘ to see its meaning right there.
- Cache
- A fast store that keeps copies of frequently used data so you don't have to fetch it from the slow source every time.
- CDN
- Content Delivery Network: many caches spread around the world that serve files from a location near each user.
- Client
- Whatever sends requests: a browser, a mobile app, or another service.
- Compression
- Making a file smaller so it's quicker to send and cheaper to store, usually by dropping detail you won't notice, like shrinking a video to suit a phone screen.
- Cookie
- A small note a website or app saves on your browser or phone and sends back on later visits, so the service can recognise the same device.
- Data centre
- A building full of servers, with its own power and cooling. Big apps run in several, often in different cities.
- DNS
- The Domain Name System: the internet's phone book, turning names like shop.example into server addresses.
- DNS resolver
- The computer, usually run by your internet provider or a public service, that looks up website addresses on your behalf and remembers recent answers so the next lookup is quick.
- domain name
- The human-friendly name of a website, like shop.example. Computers can't use it directly, so it gets turned into a number (an IP address) first.
- Handshake
- The short "hello, hello, OK" exchange two computers do before they start sending data.
- Header
- A labelled detail sent along with a request or response, like which app is asking, the language, or a login token.
- HTML
- The text file that describes a web page: its words, headings and links, and a list of the other files (pictures, styles, scripts) the browser needs to fetch to draw it.
- HTTP
- The protocol browsers and apps use to send requests and responses over the web, with methods like GET and POST.
- HTTP method
- The verb at the start of a request that says what you want: GET to read, POST to create, PUT to change, DELETE to remove.
- HTTPS
- HTTP sent through a locked, private line, so nobody between you and the website can read or change what's sent. Browsers show it with a padlock next to the address.
- IP address
- A numeric address that identifies a machine on a network, like 203.0.113.7.
- Latency
- How long one request takes, from sending it to getting the answer back. Usually measured in milliseconds (ms).
- Load balancer
- A component that receives requests and spreads them across several servers.
- p99 latency
- The 99th percentile: 99 out of 100 requests are at least this fast. It describes the slowest experiences users actually have.
- Packet
- A small piece of data travelling over the internet. Anything bigger, like a photo, is cut into many packets.
- Redirect
- A response that says "what you want is at this other address", and sends the browser there automatically.
- Request
- A message asking a server to do something, like "send me this page" or "save this order".
- Response
- The server's answer to a request: the data, a confirmation, or an error.
- Round trip
- A message going to another computer and the answer coming back. Its time is the wait you actually feel.
- Server
- A computer (or program) that waits for requests and answers them.
- Status code
- A three-digit number in every response that says how it went: 200 means OK, 404 means "no such page", 500 means the server had a problem.
- TCP
- A careful way to send data: it numbers every packet, checks they all arrived in order, and re-sends any that went missing.
- Timeout
- A limit on how long to wait for something before giving up and reporting an error.
- TTL
- Time to live: how long a cached copy is trusted before it expires and is fetched again.
- URL
- The full web address you see in the browser's address bar. It names the website and the exact page or file you want, for example https://shop.example/diwali.
Enjoyed this? Keep going for free
This lesson is a free preview. Sign up free to save your progress and earn XP, and to unlock all 232 lessons, the simulator challenges and mock interviews.
Sign up free