"What happens when you type a URL and press enter?" is the most reused interview question in infrastructure, and for good reason: the honest answer touches DNS, TCP, TLS, CDNs, load balancers and application servers in one breath. It packs a whole networking curriculum into one question.
Most people prepare for it by reading one of the famous write-ups. That produces a memorized list. The version that survives interview follow-up questions ("and what if the cache is cold?", "why does the first request cost more?") comes from having watched the steps happen and poked at them. Below is a way to build that version in an evening, using three free browser simulators, each covering one chunk of the story. Disclosure up front: I help build these; genuinely good alternatives are linked at the end.
Chunk 1: the name becomes an address
Everything starts with DNS, and DNS is where memorized answers are weakest. Most people can say "the domain gets resolved"; far fewer can say who is asked, in what order, and what happens at each hop.
The DNS Simulator steps through the resolution story interactively, on a simplified model with its own records: browser cache first, then the OS cache, then your configured resolver, and if the resolver has nothing cached, the full walk: root server, TLD server, authoritative server. Each step shows what is asked and what comes back. It is a model, not live DNS, which is the point: the walk is slowed down enough to read.
The three facts to take away from playing with it:
- Caches answer first. The browser and OS caches can resolve the name before any network question is asked, which is why the "full" DNS story you memorized often does not happen, and why cache TTLs are what stand between you and a propagated DNS change.
- The resolver does the walking, not you. Your machine asks one question; the recursive resolver deals with root, TLD and authoritative servers on your behalf.
- One machine answers many questions. Replaying the walk with different record types (A, AAAA, CNAME, MX, TXT) shows the same machinery serving addresses, aliases, mail routing and ownership proofs.
Chunk 2: the address becomes a connection
With an IP in hand, the browser opens a TCP connection, and here interviews love the follow-up: "why does TCP need a handshake and UDP does not?"
The TCP vs UDP simulator answers it by letting you break the network. You watch the SYN, SYN-ACK, ACK exchange establish a TCP connection, then flip on packet loss (the simulator randomly destroys packets in transit) and watch what each protocol does about it. In the model, TCP notices the hole and retransmits the lost data; UDP keeps firing and the lost datagrams just never arrive. The counters keep score: packets sent, received, and the retries TCP needed. It is a simplified model of retransmission, not a full TCP stack, but the asymmetry it shows is the real one.
After that, the interview answer is a tradeoff you have watched instead of a definition: TCP gives you an ordered, reliable byte stream at the price of handshakes and retransmissions; UDP strips out connection setup and recovery entirely, and anything that vanishes is upstream's problem. Which is also the setup for the modern footnote worth knowing: HTTP/3 runs over QUIC, which is built on UDP precisely to escape some of TCP's costs while rebuilding the guarantees it still needs.
Chunk 3: the connection becomes a response
The last chunk is everything between "connected" and "response received", and it is the part most answers hand-wave: where TLS happens, what a CDN actually short-circuits, and which hops a request pays for on the way to the application.
Packet Journey animates the full path: browser, DNS resolution, TCP handshake, TLS handshake, CDN edge, load balancer, web server, application, database. The reason it teaches more than a diagram is its four scenarios, which you can run back to back:
- Basic HTTP: the naive path, no encryption, straight to origin.
- HTTPS: same path plus the TLS handshake, so you see where TLS enters the sequence.
- HTTPS + CDN: the request detours to an edge node, and on a miss still travels to origin.
- HTTPS + CDN (cached): the edge answers directly, and the origin, load balancer, application and database never hear about it.
Watching scenarios 3 and 4 side by side is the fastest way to internalize what "cache hit ratio" actually buys: not a faster server, but entire hops that stop existing for most requests.
Assembling the interview answer
After the three simulators, the answer is no longer a memorized list; it is a story you can enter at any point:
The browser checks its own DNS cache, then the OS's; on a miss the recursive resolver walks root, TLD and authoritative servers. With an IP, TCP's three-way handshake establishes a connection, TLS negotiates encryption on top, and the HTTP request goes out. If the site uses a CDN, an edge node may answer from cache and the origin never sees the request; otherwise it flows through load balancer, web server and application, often to a database and back.
The difference is you can now survive the follow-ups, because for each stage you have seen the failure mode: the cold cache, the lost packet, the CDN miss.
The three simulators are part of 50+ free DevOps games and simulators, all browser-based, no signup. For going deeper on the same material: Julia Evans' Mess with DNS gives you a real subdomain to experiment on, and the classic what-happens-when repo is the encyclopedic written version of this whole question.
