HTTP Fundamentals

What is it: HTTP (HyperText Transfer Protocol) is a stateless, application-layer request-response protocol. A client sends a request (method + URL + headers + optional body); the server returns a response (status code + headers + optional body). Each request is independent — the server holds no state between requests by default.

graph LR req1["Request 1<br/>(auth token in header)"] --> anyserver1["ANY server"] req2["Request 2<br/>(auth token in header)"] --> anyserver2["ANY server<br/>(could be a different one)"] note["Every request is fully self-describing —<br/>no server needs to remember anything<br/>about a client between requests"]

Why stateless: Stateless design simplifies horizontal scaling. Any server can handle any request because no session is stored on the server. State is managed by the client (cookies, JWT tokens, URL parameters) or externalized to a shared store (Redis sessions). If state were held on the server, every request from the same user would need to go to the same server (session affinity), limiting load balancer flexibility.

Trade-offs: stateless means every request must carry enough information to be processed (authentication token, context). This increases request size. Server-side sessions (stateful) allow smaller requests but require sticky routing or a shared session store.

Worked example: a user logs in and adds an item to their cart; the load balancer sends that request to server A, which stores cart = [item1] in a local in-memory map keyed by session ID. The next request from the same browser lands on server B (no sticky routing) — server B has never seen this session ID, so its local map has no entry, and the cart appears empty even though the user just added something. Two fixes follow directly from statelessness: either make every request self-describing (a signed JWT that carries the cart contents or a reference to it, so any server can process it without shared memory), or externalize the session to a store every server can reach (cart:session_id in Redis, read and written by whichever server happens to handle the request). Sticky sessions (routing the same client to the same server every time) work around the symptom but reintroduce the scaling problem HTTP's statelessness was designed to avoid — that server becomes a single point of failure for every session pinned to it.