This flow is the starting point for every system design decision. Before you worry about databases or load balancers, understand where every millisecond goes on the way from a user's browser to your application code. Each stage introduces its own latency, failure mode, and design choice.
The diagram traces a single HTTPS request end to end. Study the stages in order, then read the latency and throughput primer to understand how each stage contributes to the total cost.
Stage-by-stage execution walkthrough
This request flow decomposes A Browser Request Reaches a Server into 5 sequential stages so you can trace where latency accumulates, which state transitions are irreversible, and where production failure modes occur.
Stage 1: DNS
The browser resolves the hostname to an IP address, using a cached answer or a recursive resolver. During this transition, the runtime enforces strict state invariants before handing control to the next stage: inputs are validated at the boundary, state mutations are ordered deterministically, and latency/resource costs are bounded so downstream consumers never observe a torn or partially initialized state.
Stage 2: TCP
A three-way handshake establishes a connection to the server, negotiating window sizes and congestion control. During this transition, the runtime enforces strict state invariants before handing control to the next stage: inputs are validated at the boundary, state mutations are ordered deterministically, and latency/resource costs are bounded so downstream consumers never observe a torn or partially initialized state.
Stage 3: TLS
The client and server negotiate a cipher suite, verify certificates, and derive session keys for encrypted communication. During this transition, the runtime enforces strict state invariants before handing control to the next stage: inputs are validated at the boundary, state mutations are ordered deterministically, and latency/resource costs are bounded so downstream consumers never observe a torn or partially initialized state.
Stage 4: HTTP
The browser sends the HTTP request over the encrypted channel. An edge proxy, CDN, or load balancer receives it first. During this transition, the runtime enforces strict state invariants before handing control to the next stage: inputs are validated at the boundary, state mutations are ordered deterministically, and latency/resource costs are bounded so downstream consumers never observe a torn or partially initialized state.
Stage 5: Application
The application processes the request, potentially consulting caches, databases, and other services before returning a response. During this transition, the runtime enforces strict state invariants before handing control to the next stage: inputs are validated at the boundary, state mutations are ordered deterministically, and latency/resource costs are bounded so downstream consumers never observe a torn or partially initialized state.
Production invariants and failure modes
The response follows the same path back through every layer, arriving at the browser as encrypted bytes that are decrypted and rendered as a page. When debugging or capacity-planning this flow in production, instrument each stage boundary separately (measuring both p50 median and p99.9 tail latency), verify what happens when an intermediate stage times out or drops packets, and ensure retry or fallback paths preserve end-to-end idempotency.