What happens when you type a URL

The classic interview question answered end to end: URL parsing, browser and DNS caches, DNS resolution, TCP and TLS handshakes, HTTP/2 and HTTP/3, CDNs and load balancers, application servers, databases and caches, the response, and rendering, with what to emphasise for system design.

Reading is half of it. See this used in a real interview: walk through Design a URL Shortener →

"What happens when you type a URL into a browser and press enter?" is one of the most common interview questions, asked at every level. It is open-ended on purpose: you can go deep on networking, browsers or backend systems. For system design, the most useful answer walks the whole path quickly, then goes deeper on the infrastructure parts: DNS, CDNs, load balancers, servers, caches and databases. Here is that walk.

1. Parsing and browser checks

The browser parses the input: is it a URL or a search? It determines the scheme (https), host (www.example.com), path and query. It checks:

• HSTS list: if the site requires HTTPS, upgrade before any request.
• Caches: is the resource already in the memory or disk cache and still fresh? If so, there may be no network request at all. See HTTP caching.
• A service worker registered for the site may answer the request itself.

2. DNS resolution

To connect, the browser needs an IP address for the host:

1. Browser DNS cache, then the operating system cache (and the hosts file).
2. The configured recursive resolver (ISP or public), which may have the answer cached.
3. If not, the resolver walks the hierarchy: a root server points to the .com TLD servers, which point to the domain's authoritative name servers, which return the record (often a CNAME to a CDN, then an A or AAAA record).
4. Answers are cached for their TTL at each layer.

The authoritative answer may depend on the user's location (GeoDNS) to send them to the nearest edge or region. See global traffic management.

3. Connection: TCP and TLS

• TCP three-way handshake (SYN, SYN-ACK, ACK): one round trip.
• TLS handshake: negotiate version and ciphers, the server presents its certificate (verified against trusted authorities), and both sides derive session keys. TLS 1.3 takes one round trip, or zero with resumption.
• With HTTP/3, QUIC over UDP combines transport and TLS setup into one round trip and avoids head-of-line blocking between streams.

Round trips dominate latency for distant servers, which is why terminating connections close to users (at a CDN edge) matters so much. See networking fundamentals.

4. The request

The browser sends an HTTP request: method, path, headers (host, cookies, accepted encodings, cache validators like If-None-Match). HTTP/2 and HTTP/3 multiplex many requests over one connection.

5. At the edge: CDN

Usually the IP belongs to a CDN edge server near the user. It:

• Serves cached content immediately (static assets, cacheable pages, images, video segments).
• Applies security rules: TLS termination, DDoS protection, web application firewall, bot checks.
• Forwards cache misses and dynamic requests to the origin, often over optimised, persistent connections.

See CDN and edge.

6. At the origin: load balancers and gateways

The request reaches the origin region:

• A load balancer picks a healthy server (round robin, least connections, consistent hashing). See load balancing.
• An API gateway may authenticate the user, apply rate limits and route by path to the right service. See API gateways.

7. Application servers

The service handles the request: parses it, checks the session or token, runs business logic, and calls other services (over gRPC, with timeouts), caches and databases. Work that does not need to finish before responding (emails, analytics) is queued for background processing. See sync vs async communication.

8. Data

• A cache (Redis, Memcached) answers hot reads in under a millisecond. See caching.
• On a miss, the database answers using indexes, possibly from a read replica. See database indexing.
• Search, recommendation or other specialised stores may be queried too.

9. The response

The server returns a status code, headers (content type, caching directives, cookies, compression) and the body, compressed with gzip or Brotli. The CDN may cache it on the way back if allowed.

10. Rendering

The browser parses HTML into the DOM, fetches CSS, JavaScript, images and fonts (more requests, many from cache or the CDN), builds the render tree, lays out the page and paints it. JavaScript may then fetch more data from APIs. Metrics like time to first byte and largest contentful paint measure this experience.

How to answer in an interview

• Give the full path in about two minutes: cache checks, DNS, TCP and TLS, CDN, load balancer, app servers, cache and database, response, rendering.
• Then go deep where the interviewer leans, or where the role is focused: DNS hierarchy and caching, TLS details, CDN caching rules, or backend scaling.
• Tie it to latency: name where round trips and milliseconds go, and what reduces them (DNS caching, connection reuse, edge termination, caches).

For a system design follow-up, the same path is a good way to explain a read request in Design a URL Shortener (DNS to the edge, cached redirect at the CDN, cache, database) or a streaming start in Design Netflix.

Checklist

• Browser checks: HSTS, caches, service workers.
• DNS: local caches, recursive resolver, root, TLD, authoritative, TTLs, GeoDNS.
• TCP and TLS handshakes; HTTP/2 and HTTP/3.
• CDN edge: cache, security, forwarding.
• Load balancer, gateway, application servers.
• Cache and database reads; background work queued.
• Response headers, compression and rendering.