HTTP · Engineering Insights

Statelessness wasn't an oversight — it's the single decision that let the web scale to billions of clients.

If the server had to remember every client between requests, it would need to keep per-client memory alive for the entire session — and any load balancer would need to route every request from a given client back to the exact same server ("sticky sessions"), which destroys the ability to freely scale horizontally or fail over instances.

Because HTTP is stateless, any server behind a load balancer can handle any request. Scaling out is just adding servers; failover is just routing around a dead one. The cost is that applications must externalize state (to a database, Redis, or a signed token) — but that cost makes horizontal scaling and failover far simpler — the remaining scaling limits move to the shared state itself, such as the database.

Each newer version targets a bottleneck in the older one, but real-world gains still depend on latency, packet loss, middleboxes, and implementation quality.

Worked scenario: one lost packet (illustrative)

Assumptions: a page fetches 12 resources at once, RTT is 100 ms, and one packet is lost mid-transfer. HTTP/1.1 spreads the transfers over 6 connections (about 2 resources each); the loss stalls only the connection it hit, so roughly 1/6 (~17%) of in-flight transfers wait for loss recovery. HTTP/2 multiplexes all 12 streams over one TCP connection; TCP delivers bytes in order, so the lost packet holds back every stream on that connection (100%) until the retransmission arrives, which costs at least about one RTT (~100 ms) and much more if recovery needs a retransmission timeout. HTTP/3 runs each stream independently over QUIC, so only the stream whose packet was lost waits (about 1/12 of the streams here). This is why HTTP/2 can lose to several HTTP/1.1 connections on lossy links, while its single connection and header compression still win on clean ones.

Both are ways to design an HTTP API — they differ in what the URL and verb are supposed to represent.

The same handful of mistakes show up across almost every HTTP-based system.

Is HTTP/2 always faster than HTTP/1.1?

Usually, but not universally — on a very low-latency, low-loss network the difference can be negligible, and HTTP/2's single-connection design can occasionally underperform multiple HTTP/1.1 connections if packet loss or implementation quirks dominate. In practice, for typical internet conditions with many small resources, HTTP/2 is often a clear win.

Why doesn't every site use HTTP/3 yet?

QUIC/UDP is sometimes blocked or throttled by corporate firewalls and some ISPs, and server-side QUIC support is newer/less battle-tested than mature TCP stacks. Most CDNs support it as an option with automatic fallback to HTTP/2.

Do I need cookies if I use JWTs?

No. A JWT is a token format; a cookie is one way to store and send that token. In browser apps, an HttpOnly cookie is often safer than exposing the token to JavaScript, while non-browser clients commonly send Authorization: Bearer <token> directly.

What's the difference between a reverse proxy and an API gateway?

An API gateway is typically a reverse proxy with API-specific features layered on top — request/response transformation, auth policy, rate limiting per API key, and sometimes request aggregation. See API Gateway fundamentals for the fuller boundary, and Reverse Proxy fundamentals for the overlap.

Three shapes cover most production HTTP topologies you'll encounter.