Request Lifecycle

What is it: The full journey of an HTTPS API request, from the moment the client calls fetch("https://api.example.com/users") to receiving the response.

Full flow:

sequenceDiagram participant App as Client app participant DNS participant Srv as Server App->>DNS: 1. resolve api.example.com (0-300ms, 0 if cached) DNS->>App: IP address App->>Srv: 2. TCP handshake (~1 RTT) App->>Srv: 3. TLS handshake (~1-2 RTT, 0 if resumed) App->>Srv: 4. HTTP request sent Note over Srv: 5. Server processing:<br/>routing -> middleware -> business logic -> DB query -> serialize Srv->>App: 6. Response transmitted

  1. DNS resolution (0–300ms, cached = 0ms): Browser cache → OS cache → /etc/hosts → recursive resolver → root → TLD → authoritative server. Result: IP address of api.example.com. Cached for TTL duration.

  2. TCP connection (~1 RTT = 50ms on a typical internet connection): Client sends SYN → server sends SYN+ACK → client sends ACK. After this, the TCP connection is established. With HTTP keep-alive / connection pooling, existing connections skip this step.

  3. TLS handshake (TLS 1.2: ~2 RTT = 100ms; TLS 1.3: ~1 RTT = 50ms; resumed: ~0ms): Cipher negotiation, certificate exchange, key derivation. After this, all bytes are encrypted.

  4. HTTP request sent (negligible — just packet sending): Client sends HTTP/1.1 or HTTP/2 request: method, URL, headers (Host, Authorization, Content-Type), optional body.

  5. Server processing (1–100ms depending on workload):

  6. Framework routing: match URL to handler
  7. Middleware: auth verification, rate limiting, logging
  8. Business logic: validation, computation
  9. Database query: most latency is here — a cold query with a B+Tree lookup takes 1–10ms, a slow query without index can take seconds

  10. Response serialization: JSON marshaling

  11. Response transmitted (function of response size and bandwidth): Server sends status code + headers + body. Client reads, parses JSON (or other format), returns to caller.

Where latency hides: - DNS cache miss: 100–300ms (use long TTLs for stable services) - New TCP connection: 1 RTT (use connection pooling, keep-alive) - TLS handshake: 1–2 RTT (use TLS session resumption, TLS 1.3) - DB query: most often the dominant term (add indexes, cache hot data) - Serialization: large response bodies slow down serialization (return only needed fields) - Geographic distance: a 1 RTT from Vietnam to US = 150–200ms (use CDN/regional servers)

Why a request can be slow: - Missing index on DB query (full table scan) - No connection pooling (new TCP+TLS per request) - Synchronous calls to slow downstream services (should be async or cached) - Large response body (SELECT * instead of specific columns) - DNS TTL too short (frequent DNS lookups) - No CDN for static assets (every request goes to origin)