Every request starts with a question — "where is example.com?" — and the answer is fetched in under 30 milliseconds, hopefully. The infrastructure that makes that possible is the most overlooked piece of every system you'll ever build.
Before caching, sharding, and orchestration, every system depends on one simple promise: users can reach your service. That promise is powered by DNS, transport protocols, and HTTP semantics. A deep understanding of these layers separates engineers who debug outages in minutes from those who stare at dashboards for hours. This module is the long form of "what happens when a user types a URL and presses Enter" — the full request journey, all the way down.
The request journey from start to finish
A user types https://example.com/cart and presses Enter. Before a single byte of your application code runs, eight things happen in roughly this order, each one introducing latency, failure modes, and optimisation opportunities.
- 1 · DNS
- Browser asks the OS, OS asks the resolver, resolver asks root → TLD → authoritative. ~1 ms warm, ~50 ms cold. TTL governs how long the answer is reused.
- 2 · TCP handshake
- SYN → SYN-ACK → ACK. One round-trip. ~5 ms same-region, ~80 ms cross-region.
- 3 · TLS handshake
- ClientHello → ServerHello + cert → key exchange → Finished. One RTT for TLS 1.3, two for TLS 1.2. Resumed sessions are cheaper.
- 4 · HTTP request
- Method, path, headers, body. Multiplexed in HTTP/2 and HTTP/3 over the same connection.
- 5 · Edge / CDN
- Request reaches a PoP. Cacheable responses are served from there; the rest are forwarded to origin.
- 6 · Load balancer
- L7 LB picks a backend, terminates TLS, applies WAF rules.
- 7 · Application
- Your code runs. Hits cache, hits DB, fans out to other services, returns a response.
- 8 · Response and connection reuse
- Bytes flow back. The TCP/TLS connection is kept alive (keep-alive) for the next request.
DNS — the part you forget about until it breaks
DNS resolves human-readable hostnames to IP addresses through a hierarchical, distributed database. There are four roles in the system, and confusing them is the most common source of DNS misunderstanding.
The piece in your OS or browser. Asks a recursive resolver and parses the answer. Has no recursion logic of its own.
The legwork-doer. 1.1.1.1, 8.8.8.8, your ISP's resolver. Caches aggressively. Returns final answers to stub resolvers.
The source of truth for a zone. Owns example.com's records. The recursive resolver eventually queries it.
13 root servers (anycast, hundreds of physical machines). Each TLD (.com, .org) has its own authoritative servers. The resolver descends the tree.
The records you'll touch
| Type | What it does | Common gotcha |
|---|---|---|
A | Hostname → IPv4 | — |
AAAA | Hostname → IPv6 | Misconfigured AAAA but no v6 reachability = silent breakage on dual-stack hosts. |
CNAME | Alias to another name | Cannot coexist with other records at the same name. Can't be at zone apex. |
MX | Mail server for the domain | Priority field — lower number wins. |
TXT | Free-form text — SPF, DKIM, verification | SPF record limits: 10 DNS lookups, 255 chars per string. |
NS | Authoritative name servers for a zone | Must match what the registrar's TLD has set. Mismatch = lame delegation. |
SOA | Zone metadata — serial, TTLs, expiry | Negative-caching TTL governs how long NXDOMAIN is remembered. |
CAA | Which CAs may issue certs for this domain | Missing CAA = any public CA may issue. Set this. |
TTL — the only DNS dial that matters
TTL (time-to-live) tells resolvers how long to cache an answer. It governs how fast a record change propagates and how often the authoritative server is hit. The trade-off is unforgiving:
- Long TTL (24 h+)
- Quiet authoritative server, fast lookups for users, cheap. But a planned migration takes a day to take effect, and unplanned ones hurt.
- Short TTL (60 s)
- Rapid failover, fast traffic-shaping. But ~1,400× more queries to the authoritative server than a 24 h TTL, and DNS-based load balancing becomes feasible.
- Pre-migration trick
- Drop TTL to 60s 24-48 hours before a planned change, so the change actually takes effect quickly. Restore long TTL afterwards.
TCP and TLS — the two layers above DNS
Once DNS returns an IP, the browser opens a TCP connection. TCP is a reliable byte-stream over an unreliable network: SYN/SYN-ACK/ACK to handshake, sequence numbers and acknowledgements for delivery, sliding window for flow control, congestion control to avoid melting the network. TLS sits on top, layering encryption, integrity, and identity (via certificates) onto the byte stream.
The numbers worth knowing: a fresh TCP+TLS handshake on a 50 ms RTT link is ~150 ms before the first byte of HTTP. With TLS 1.3 + TCP Fast Open, that drops to one round trip. With QUIC (HTTP/3), the handshake is folded in and the connection comes back in 0-RTT for resumed sessions. Connection reuse — keep-alive on HTTP/1.1, multiplexing on HTTP/2 and HTTP/3 — is what makes the modern web feel fast.
HTTP versions — what changed and what to use
| Version | Transport | Concurrency model | Headers |
|---|---|---|---|
| HTTP/1.0 (1996) | TCP | One request per connection | Plain text |
| HTTP/1.1 (1997) | TCP, keep-alive | Pipelining (rarely used) | Plain text |
| HTTP/2 (2015) | TCP + TLS | Streams, multiplexed | HPACK compressed |
| HTTP/3 (2022) | QUIC over UDP | Streams, no head-of-line blocking | QPACK compressed |
Use HTTP/2 for everything; the multiplexing alone beats HTTP/1.1 in most cases. Use HTTP/3 if your edge supports it — Cloudflare, Fastly, Akamai all do — for clients on lossy or mobile networks, where head-of-line blocking in TCP hurts. The application semantics are identical; the wire format is what changed.
The hard cases
CNAME at the zone apex (example.com with no subdomain) — the spec forbids it because the apex must hold SOA and NS records. Cloud providers offer "ALIAS" or "ANAME" records that simulate apex CNAMEs by resolving server-side. Use them; don't try to fight the spec.
Practical defaults
- Use a managed DNS provider (Route 53, Cloudflare, NS1) — running your own authoritative servers is rarely worth the operational burden.
- Set CAA records to constrain which CAs may issue certs. A two-line addition that prevents a class of breach.
- Default TTLs: 300 s for records that might change, 86400 s for ones that won't, 60 s temporarily before a planned change.
- Always use HTTP/2 or HTTP/3 over TLS 1.3. There is no current scenario where plain HTTP or TLS 1.2 is the right answer for new deployments.
- Monitor DNS query latency the same way you monitor application latency. A flaky resolver is invisible until it isn't.