Request Lifecycle
What happens from the moment you type a URL to seeing the page? Every step explained.
1The Mail Delivery Analogy
2Complete Request Flow
When you type https://example.com/api/users and hit Enter:
DNS Resolution
Browser needs to convert 'example.com' to an IP address like '93.184.216.34'
- 1. Check browser cache (previously resolved)
- 2. Check OS cache (/etc/hosts)
- 3. Query DNS resolver (usually ISP)
- 4. Recursive lookup: Root → TLD (.com) → Authoritative
TCP Connection
Three-way handshake to establish a reliable connection
- 1. Client sends SYN (synchronize)
- 2. Server responds SYN-ACK (acknowledge)
- 3. Client sends ACK (connection established)
- 4. Now both sides can send data reliably
TLS Handshake
Establish encrypted channel using certificates
- 1. Client Hello: supported cipher suites, random number
- 2. Server Hello: chosen cipher, certificate
- 3. Client verifies certificate against CA
- 4. Key exchange: agree on session keys
- 5. All further communication encrypted
HTTP Request
Browser sends HTTP request with headers and optional body
- 1. Method: GET, POST, PUT, DELETE, etc.
- 2. Headers: Host, User-Agent, Accept, Cookies, Auth
- 3. Body: JSON payload for POST/PUT
GET /api/users HTTP/1.1 Host: example.com Authorization: Bearer eyJhbGc... Accept: application/json Cookie: session=abc123
Server Processing
This is where your application code runs
- 1. Load balancer routes to available server
- 2. Web server (Nginx) receives request
- 3. Application server processes business logic
- 4. Database queries, cache lookups
- 5. Build response
HTTP Response
Response includes status code, headers, and body
- 1. Status: 200 OK, 404 Not Found, 500 Error, etc.
- 2. Headers: Content-Type, Cache-Control, Set-Cookie
- 3. Body: HTML, JSON, images, etc.
- 4. May be compressed (gzip)
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600
Content-Encoding: gzip
{"users": [{"id": 1, "name": "Alice"}]}Browser Rendering
Browser parses and renders the response
- 1. Parse HTML → Build DOM tree
- 2. Parse CSS → Build CSSOM
- 3. Execute JavaScript
- 4. Layout: calculate positions
- 5. Paint: draw pixels on screen
3Latency at Each Step
Typical Request Timeline (200ms total)
Server processing (40%) is usually the biggest chunk and what you can control. DNS caching, connection reuse (keep-alive), and CDNs help with the rest.
4Key Optimizations
- • DNS prefetch (rel="dns-prefetch")
- • Use fewer unique domains
- • Lower TTL for failover
- • Keep-alive connections
- • HTTP/2 multiplexing
- • TLS session resumption
- • Reduce payload size
- • Compression (gzip, brotli)
- • CDN for static assets
- • Caching (Redis)
- • Database indexes
- • Async processing
- • Chunked transfer
- • Streaming responses
- • Edge computing
- • Lazy loading
- • Code splitting
- • Image optimization
5HTTP/1.1 vs HTTP/2 vs HTTP/3
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Connections | Multiple (6 per domain) | Single (multiplexed) | Single (QUIC/UDP) |
| Head-of-line blocking | Yes | Partial (TCP level) | No |
| Header compression | No | HPACK | QPACK |
| Server push | No | Yes | Yes |
| Transport | TCP | TCP | QUIC (UDP) |
⚡Interactive: See the Request Lifecycle
Click through each step to see how a request travels from your browser to the server and back.
Request Lifecycle Simulator
Watch how a request travels through the system
6Key Takeaways
7Interview Follow-up Questions
Interview Follow-up Questions
Common follow-up questions interviewers ask
8Test Your Understanding
Test Your Understanding
5 questions
What is the correct order of steps when loading a webpage over HTTPS?
What does 'Time to First Byte' (TTFB) measure?
Which HTTP/2 feature allows multiple requests to share a single TCP connection?
Where is DNS caching typically NOT performed?
A CDN primarily helps reduce latency by: