Full-Stack Web Architecture: The Request Lifecycle from Browser to Database

A junior developer types https://mydukaan.in/products into a browser, watches the page load, and thinks: "React fetched some JSON and rendered HTML."

That is like looking at an airplane and saying it is just a metal tube with wings.

Between the moment your user taps Enter on a budget Android phone in Patna and the moment pixels illuminate the screen, dozens of distributed protocols execute in milliseconds. Sockets open, cryptographic keys exchange across ocean cables, reverse proxies route headers, and database engines read disk pages.

If you want to move beyond building toy dashboard clones, you need to understand the full mechanical journey of a web request.

Phase 1: DNS Resolution (Finding the Server)

Browsers cannot send HTTP packets to domain names. They require a 32-bit IPv4 address (e.g. 142.250.190.46) or a 128-bit IPv6 address.

The browser kicks off a recursive lookup chain:

1. Local Browser Cache: Chrome checks its internal DNS cache (chrome://net-internals/#dns).
2. Operating System Cache & Hosts File: The OS checks whether the domain was resolved recently or mapped in /etc/hosts.
3. Recursive Resolver: The request leaves your router and hits your ISP resolver or public resolver (like Cloudflare 1.1.1.1 or Google 8.8.8.8).
4. The Root and TLD Servers: If uncached, the resolver queries the Root server (.), which directs it to the .in Top-Level Domain (TLD) server, which points to the authoritative nameserver for mydukaan.in.

The authoritative nameserver returns the IP address along with a Time-To-Live (TTL) value (e.g. 300 seconds). The resolver caches the record so subsequent queries take 0 milliseconds.

Phase 2: TCP Connection and TLS 1.3 Handshake

Once the browser has the IP address, it must establish a secure, reliable transport socket.

1. The TCP 3-Way Handshake

Before transmitting a single byte of data, client and server synchronize sequence numbers:

• SYN: Client sends a synchronize packet with random sequence number X.
• SYN-ACK: Server acknowledges with X+1 and its own sequence number Y.
• ACK: Client acknowledges with Y+1. Connection established.

This takes 1 Round Trip Time (RTT). If your server is in Frankfurt and your user is in Hyderabad, that round trip costs 120 milliseconds of pure physics latency.

2. The TLS 1.3 Handshake

In modern HTTPS, TLS 1.3 negotiates encryption in a single additional round trip (1-RTT). The client sends its supported cipher suites and an ephemeral Diffie-Hellman public key share inside the initial ClientHello.

The server replies with its certificate, public key share, and signature. Both sides derive a symmetric session key (AES-GCM or ChaCha20-Poly1305) without ever transmitting the secret key over the wire.

Client (Browser)                          Server (Reverse Proxy)
   │                                               │
   ├─── TCP SYN ──────────────────────────────────►│ [1 RTT: TCP Handshake]
   │◄── TCP SYN-ACK ───────────────────────────────┤
   ├─── TCP ACK + TLS 1.3 ClientHello (KeyShare) ─►│
   │                                               │ [1 RTT: TLS Handshake]
   │◄── TLS ServerHello + Cert + Finished ─────────┤
   │                                               │
   ├─── HTTP/2 GET /products (Encrypted) ─────────►│ [Secure Pipeline Open]

Phase 3: The Edge, Nginx, and Reverse Proxies

The request does not hit your Node.js or Go application server directly. In production, it terminates at an Edge CDN (Cloudflare/Fastly) or a reverse proxy like Nginx or Caddy.

The reverse proxy performs four crucial tasks:

• TLS Termination: Handles high-CPU cryptography at the edge so your internal application code only speaks plain HTTP over a private VPC socket.
• Static Asset Offloading: Serves cached images, CSS, and fonts directly from disk or memory without waking up your backend runtime.
• Compression: Compresses outgoing text payloads using Brotli (br) or Gzip, reducing transfer sizes by up to 75%.
• Rate Limiting & Security: Drops volumetric DDoS attacks and malicious bots before they consume backend database connections.

# Minimal production Nginx upstream configuration
upstream backend_api {
    server 127.0.0.1:4000;
    keepalive 32; # Pool active TCP connections to backend
}

server {
    listen 443 ssl http2;
    server_name mydukaan.in;

    # Compress responses on the fly
    brotli on;
    brotli_types text/plain text/css application/json application/javascript;

    location / {
        proxy_pass http://backend_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Phase 4: Backend Execution and Database Query

Now your Node.js, Go, or Python application receives the request headers and body. It parses the cookie or Bearer token, checks user session validity in Redis, and executes the SQL query in PostgreSQL.

This is where Time to First Byte (TTFB) is decided:

• Good Backend: Connection pool is warm, index scan takes 2ms, serialization takes 1ms. Total TTFB: under 60ms.
• Bad Backend: Sequential scan on unindexed table takes 1,400ms, ORM executes 50 N+1 queries in a loop. Total TTFB: 1.8 seconds.

Phase 5: Rendering Models: SPA vs SSR vs Static

How the client receives HTML dictates performance on real devices:

Phase 6: Browser Critical Rendering Path

When the browser receives the raw HTML bytes, it does not display them all at once. The browser engine parses and paints in sequence:

1. DOM Construction: Parse HTML tokens into the Document Object Model (DOM) tree.
2. CSSOM Construction: Parse CSS stylesheets and style tags into the CSS Object Model tree. CSS is render-blocking: the browser will not paint until CSSOM is ready.
3. Render Tree: Combine DOM and CSSOM, ignoring invisible elements (like display: none).
4. Layout (Reflow): Calculate exact pixel coordinates and box sizes for every visible element on the viewport.
5. Paint: Rasterize boxes into actual color pixels on layers.
6. Composite: Combine GPU texture layers onto the screen.

The Real Web Engineering Checklist

1. Host Near Your Users: If your customers are in India, deploy your servers in Mumbai (ap-south-1), not Virginia (us-east-1). Save 150ms of speed-of-light latency on every TCP connection.
2. Enable HTTP/2 or HTTP/3: Stop bundling 100 images into a CSS sprite. HTTP/2 multiplexes dozens of files over a single TCP socket simultaneously.
3. Set Cache-Control Headers: Give static hashed assets (e.g. bundle.a81f9.js) a 1-year immutable cache header: Cache-Control: public, max-age=31536000, immutable.
4. Measure Real Core Web Vitals: Track Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) on real budget smartphones, not on a 64GB M3 Max laptop.

Understand the physics of the web platform, build with mechanical empathy for low-spec hardware, and your web applications will run circles around bloated templates.