What Happens When You Enter a URL?

This is the single most common system-design and networking interview question, precisely because there's no way to fake an answer — reciting "DNS, then TCP, then HTTP" gets you partway, but a Google/Microsoft/Amazon-level interviewer will pick any one step and drill down until you either demonstrate real understanding or run out of depth. The bar isn't reciting the pipeline once — it's being able to go three or four follow-ups deep on any single arrow in it, DNS resolution, the TCP handshake, TLS, load balancing, the database call, without losing the thread of what you were originally answering.

Why This Question Comes Up

Typing a web address and hitting enter feels like one simple action, but behind the scenes it sets off a whole chain of separate systems — finding the right computer on the internet, opening a secure connection to it, asking it for the page, and getting an answer back — each one built and run by different companies and pieces of software that all have to work together correctly, in the right order, in a fraction of a second.

Where This Is Used

• Every single webpage load, app API call, and streaming video request on the internet goes through some version of this sequence.
• When a site like Amazon or your bank's app "goes down," it's almost always one of these steps failing, not the entire internet failing.
• Companies like Cloudflare and AWS build entire businesses around speeding up or securing one or two of these steps (like DNS lookup or the secure-connection setup).
• Mobile apps checking for new messages, food-delivery apps tracking your order, and video calls all rely on this same underlying chain of handoffs.

A Day-to-Day Example

It's like mailing a letter to a company at a well-known nickname instead of their real street address. First you look up the nickname in a directory to get the actual address (DNS). Then a courier confirms someone is actually there to receive mail before handing anything over (opening a connection). Then, for anything sensitive, you and the receiver agree on a secret code so no one along the way can read the letter (a secure handshake). Only then does your actual letter — your request — get delivered, read, and answered.

The Full Pipeline

Walk through https://api.example.com/orders/123 end to end:

1. DNS resolution — the browser/OS resolves api.example.com to an IP address, checking browser cache → OS cache → router cache → ISP resolver before a full recursive lookup through root → .com TLD → example.com's authoritative name servers.
2. Transport connection setup — a TCP 3-way handshake (SYN / SYN-ACK / ACK) opens a connection to the resolved IP on port 443, or, for HTTP/3, a QUIC connection is established over UDP instead.
3. TLS handshake — client and server negotiate a cipher suite, the server presents its certificate (validated against a trusted CA chain up to a root CA the OS/browser trusts), and both derive a shared session key — TLS 1.3 does this in one round trip; QUIC folds it into connection setup itself.
4. HTTP request sent — over the now-encrypted connection, the browser sends GET /orders/123 with headers (Host, Authorization, cookies, Accept, etc.).
5. Request reaches the edge — often a CDN or WAF first (checking for a cached response or blocking malicious traffic), then a load balancer / reverse proxy, which may terminate TLS and apply routing rules.
6. Load balancer routes to a backend instance — using a balancing strategy (round-robin, least-connections) across healthy instances, discovered via the mechanisms covered in the service-discovery page.
7. Backend queries cache and/or database — typically checking a cache (Redis) first, falling back to the database (PostgreSQL) on a miss.
8. Response flows back — database → backend → load balancer → client, each hop adding its own latency.
9. The browser processes the response — for JSON, application code parses and updates the UI; for HTML, the browser parses it, builds the DOM, fetches render-blocking CSS/JS, builds the CSSOM, computes layout, and paints — often kicking off dozens of additional requests that repeat parts of this whole pipeline.

Client                DNS      LB/Edge      Backend      Cache      DB
  │                    │           │            │           │        │
  │── resolve domain ─►│           │            │           │        │
  │◄──── IP addr ──────│           │            │           │        │
  │                                │            │           │        │
  │── TCP SYN ────────────────────►│            │           │        │
  │◄─ SYN-ACK ─────────────────────│            │           │        │
  │── ACK ──────────────────────────►│            │           │        │
  │── TLS ClientHello ───────────────►│            │           │        │
  │◄─ TLS ServerHello + cert ─────────│            │           │        │
  │── TLS Finished ───────────────────►│            │           │        │
  │                                │            │           │        │
  │── GET /orders/123 ────────────────►│            │           │        │
  │                                │── route ──►│            │        │
  │                                │            │── GET ────►│        │
  │                                │            │◄─ miss ────│        │
  │                                │            │── SELECT ───────────►│
  │                                │            │◄──── row ────────────│
  │                                │            │── SET cache ────────►│
  │                                │◄─ 200 OK ──│           │        │
  │◄──────── 200 OK + JSON ───────────│            │           │        │
  │                                │            │           │        │
  │  (browser/app code parses JSON, renders UI)               │        │

Going Deep: The Follow-Up Chain

A strong candidate can be pulled off the "happy path" into any single step and keep answering. This is the chain interviewers actually run:

Interviewer: "How does TCP guarantee reliability?"

You: Every byte sent gets a sequence number. The receiver sends back an ACK acknowledging the highest contiguous sequence number it has received, so the sender always knows what's been received successfully. Each segment carries a checksum so the receiver can detect corruption and simply not ACK a corrupted segment. If the sender doesn't get an ACK for a segment within a computed retransmission timeout, it resends it — so loss is handled by absence of an ACK, not by any explicit "nack" mechanism. Segments can also arrive out of order (different network paths, retransmissions), and TCP uses the sequence numbers to reassemble them in the correct order before handing the byte stream up to the application — the application never sees out-of-order or duplicate data.

Interviewer: "What if the ACK itself is lost, not the original data?"

You: From the sender's perspective this is indistinguishable from the original segment being lost — it doesn't get an ACK either way. Its retransmission timer fires and it resends the segment. If the original data actually did arrive and only the ACK was lost, the receiver gets a duplicate segment, recognizes the sequence number as one it's already seen, drops it (or re-ACKs it), and no harm is done — TCP is idempotent at this layer by design specifically so it can be robust to ACK loss without needing to reason about it as a special case. This is also why TCP is a "positive acknowledgment with retransmission" protocol — it never needs to know what got lost, only that it hasn't heard back yet.

Interviewer: "What if the network is congested?"

You: TCP uses congestion control to avoid making congestion worse. It starts conservatively with slow start — the sender's congestion window begins small and roughly doubles every round trip as ACKs confirm data is getting through, until it either hits a threshold or detects loss. Once it's past that ramp-up, it shifts to additive-increase/multiplicative-decrease (AIMD): the window grows by one segment per round trip on success, but is slashed (typically halved) the moment loss is detected, since loss is treated as a congestion signal. This is why TCP throughput on a lossy or congested link looks like a sawtooth over time — climb slowly, drop sharply, repeat — and it's also why a single retransmission can meaningfully cut your effective throughput, not just delay one segment.

Interviewer: "Why not just use UDP instead, since it has less overhead?"

You: UDP gives you none of the above for free — no sequencing, no retransmission, no congestion control, no guarantee a packet arrives at all. HTTP needs the request and response bytes to arrive complete, in order, and exactly once, which is exactly what TCP (or QUIC, which rebuilds equivalent guarantees on top of UDP) provides. UDP is the right choice when an application can tolerate loss and wants to handle timing itself — live video/voice, DNS queries (a single small request/response, where the application just retries on timeout) — but a lost or reordered byte in the middle of an HTTP response body isn't something you can just drop and move on from. QUIC is the interesting middle ground: it runs over UDP but reimplements TCP's reliability and adds per-stream loss recovery, so one lost packet doesn't stall unrelated streams the way TCP's single ordered byte-stream can (head-of-line blocking).

Interviewer: "Your API is slow. How do you find the problem?"

You: I wouldn't guess — I'd pull a trace for the slow request and read the waterfall across every step in this exact pipeline: DNS resolution time, TCP/TLS setup time, time spent at the load balancer, backend processing time, the cache lookup, the database query, and any external call like an LLM API. In a real example, a 2-second request broke down as DNS 10ms, TLS 20ms, backend routing 20ms, Redis 5ms, Postgres 50ms, and an LLM call at 1800ms — 90% of the latency was one external call, and no amount of optimizing the database or infra would have moved the needle. That's the value of distributed tracing over guessing: it converts "the API is slow" into "this specific span, in this specific service, is slow," and tells you exactly where to spend optimization effort instead of where it's comfortable to look first.

The Bigger Picture

Zoom out from one request and this pipeline is really one path through a much larger system — the same shape behind most modern backend and AI-powered products:

                    USER / MOBILE APP
                           │
                           ▼
                         DNS
                           │
                           ▼
                    IP / NETWORK
                           │
                           ▼
                    TCP / QUIC
                           │
                           ▼
                         TLS
                           │
                           ▼
                         HTTP
                           │
                           ▼
                   CDN / WAF / LB
                           │
                           ▼
                    API Gateway
                           │
                           ▼
                   BACKEND SERVICE
                     /      │       \
                    /       │        \
                 Redis   PostgreSQL  Queue
                                       │
                                       ▼
                                    Worker
                                       │
                                +------+------+
                                ▼             ▼
                            LLM API       Vector DB
                                │             │
                                +------+------+
                                       ▼
                                    Response

For a backend or AI-engineer role, being able to explain every arrow in that diagram — what protocol runs on it, what it's for, how it fails, what it costs in latency, how you'd scale it, and what its security implications are — matters far more than being able to define any one term in isolation. "DNS resolves a hostname to an IP" is a definition; "DNS adds a cacheable 10-50ms lookup that can be skipped entirely with a low TTL and edge caching, and its failure mode is a full outage disguised as 'the site is down' when it's actually just resolution failing" is understanding. That gap — between reciting the pipeline and being able to reason about any single edge in it under pressure — is exactly what this whole study section is built to close.

System Design Tie-in

This literally is the opening of most system design interviews. "Design a URL shortener," "design Twitter's timeline," "design an AI chat product" — nearly all of them start with an interviewer wanting to see this exact request flow (client → DNS → network → load balancer → service → data layer → response) sketched out before the conversation narrows into the specifics of that system (how the shortener generates IDs, how the timeline fans out, how the chat product streams tokens). Candidates who can draw this pipeline fluently, and then adapt it to the exact system prompt, have already cleared the first and most common filter question before the "interesting" design decisions even start.