The Runtime Theory
easyClientFoundations#request-path#end-to-end-thinking

What Happens When You Type a URL and Press Enter?

The classic system design opener — trace the journey from keystroke to page render and identify the design choices at each layer.

TRT practice prompt — not a verified question from a named employer.

The Runtime Theory Team2 min read

A strong answer

I would first clarify what scope the interviewer means — the full path from keyboard to pixels, or just the server-side handling. Then I would walk through the major stages, naming the design decisions and failure modes at each one.

1. Keystroke to URL parsing. The browser parses the URL, checks the HTTP cache for a fresh response, and if none exists, begins the network path.

2. DNS resolution. The browser checks its own cache, then the OS cache, then the configured recursive resolver. DNS is a separate system with its own availability and caching concerns — a DNS failure means the request never leaves the client.

3. TCP connection. A three-way handshake establishes a connection to the resolved IP. For HTTPS, this happens inside the TLS handshake. TCP connection setup costs one round-trip and cannot be avoided without connection reuse or HTTP/3's 0-RTT.

4. TLS negotiation. If this is HTTPS, the client and server negotiate a cipher suite and verify certificates. A TLS 1.3 handshake completes in one round-trip after TCP; TLS 1.2 costs two. Certificate verification depends on the OS trust store and online revocation checks.

5. HTTP request. The browser sends the request. An edge proxy, CDN, or load balancer receives it first. The request may be answered from a cache at any of these layers, short-circuiting everything that follows.

6. Application processing. The application receives the request, authenticates and authorizes the caller, and does the work. This is where the cache-hit-or-miss trace plays out — a hit avoids a database round-trip; a miss pays that cost and populates the cache for the next caller.

7. Response back. The response follows the same path backward through every layer, arriving at the browser as encrypted bytes that are decrypted, parsed, and rendered.

The key design insight: most of the latency lives in the network hops, not the application code. A well-designed system minimizes the hops on the critical path and makes the failure modes at each hop observable and graceful.

Follow-up directions

  • Compare HTTP/1.1 connection reuse, HTTP/2 multiplexing, and HTTP/3's connectionless transport.
  • Explain how a CDN edge cache changes the answer — now most requests never reach your origin.
  • Discuss what happens when DNS returns a stale or poisoned record.

This answer walks

Practice follow-ups

  1. 01What changes if the DNS answer is already cached in the browser?
  2. 02What if the server is behind a CDN edge with a cache hit?
  3. 03How does HTTP/3 change the TLS and TCP handshake cost?

More interviews in this topic

One dispatch a week

The trace behind each question, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started

Sign in to save your learning progress.

Sign in to save