HTTP — HyperText Transfer Protocol

HTTP is a request-response protocol: a client sends a request, the server sends a response. It is stateless — each request is independent, and the server doesn't remember previous requests (unless you add cookies or sessions).

This statelessness is both a strength and a weakness: it makes HTTP easy to scale (any server can handle any request) but means the application must manage state through other means (cookies, tokens, server-side sessions).

HTTP methods and their semantics:

Safe methods have no side effects — calling them doesn't change server state. They can be cached and prefetched.

Idempotent methods can be safely retried — doing them once or 100 times produces the same result. This matters for unreliable networks: if a request times out, you can safely retry idempotent methods but not non-idempotent ones.

HTTP status codes tell the client what happened:

• 2xx Success: 200 OK, 201 Created, 204 No Content
• 3xx Redirect: 301 Moved Permanently, 304 Not Modified (cache hit — don't re-download)
• 4xx Client error: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
• 5xx Server error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

In system design, 429 (rate limited) and 503 (unavailable) are especially important — they signal the client to back off or retry. Always include a Retry-After header with 429 so the client knows how long to wait.

Common mistakes:

• Returning 200 OK with an error body. This breaks HTTP semantics and client error handling. Use 4xx/5xx.
• Returning 500 for client errors (bad input). Use 400.
• Not returning 201 Created when a resource is created.

HTTP version evolution:

HTTP/1.1 (1997): text-based protocol. One request per TCP connection (later, pipelining was added but suffered from head-of-line blocking). Headers sent as plain text on every request (cookies can be several KB). Still the most widely deployed version.

HTTP/2 (2015): binary framing. Multiple requests multiplexed over a single TCP connection — no head-of-line blocking at the HTTP level. Header compression (HPACK) reduces overhead. Server push (deprecated in practice). Adopted by most modern APIs.

HTTP/3 (2022): runs over QUIC (UDP-based). Eliminates TCP head-of-line blocking entirely — if one stream is slow, others aren't blocked. Faster connection setup (0-RTT — can send data on the first packet). Better on mobile networks (survives IP changes). Default in Chrome and Cloudflare.

The semantics (methods, status codes, headers) are the same across versions — only the transport changes. HTTP/3 is backward-compatible with HTTP/2 and HTTP/1.1 at the application layer.

Key HTTP headers for system design:

Caching:

• Cache-Control: max-age=60 — cache for 60 seconds.
• ETag: "abc123" — content hash. Client sends If-None-Match: 'abc123' — if unchanged, server returns 304 Not Modified (saves bandwidth).
• Last-Modified / If-Modified-Since — timestamp-based caching.

Performance:

• Connection: keep-alive — reuse TCP connection (HTTP/1.1 default).
• Accept-Encoding: gzip — compress response.
• Transfer-Encoding: chunked — stream response without knowing total size.

Security:

• Authorization: Bearer {token} — auth token.
• Strict-Transport-Security — force HTTPS.
• Content-Security-Policy — prevent XSS.

Rate limiting:

• X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset — tell client their quota.
• Retry-After: 30 — wait 30 seconds before retrying (sent with 429).

HTTP/1.1 vs HTTP/2 vs HTTP/3 — side by side.

The semantics (methods, status codes, headers) are unchanged across all three versions — only the transport and framing change. This is by design: HTTP/3 is fully backward-compatible with HTTP/2 at the application layer.

Idempotency keys in practice. Stripe popularized the pattern: every POST request includes an Idempotency-Key header (a client-generated UUID). The server treats any two requests with the same key as the same logical operation — the second one returns the cached result of the first instead of re-processing.

The flow is:

1. Client generates a UUID for this logical operation (e.g., 'charge this user $50 for order 1234').
2. Client sends POST /v1/charges with Idempotency-Key: <uuid>.
3. Server checks the idempotency store (Redis, DynamoDB, or a DB table): is this key present?
   • If yes → return the stored response.
   • If no → process the request, store the response keyed by the UUID with a TTL (e.g., 24h), return the response.
4. If the network fails before the client receives the response, the client retries with the same UUID. The server returns the stored response (or returns 'still processing' if the original is in flight).

This converts a non-idempotent POST into a safely-retryable operation. Without it, a network blip during a payment could double-charge the user, or worse, partially charge and partially refund — leaving the system in an ambiguous state that requires manual reconciliation.

The same pattern applies to webhook delivery, background job processing, and any 'do this exactly once' API. The catch: 'exactly once' is impossible in distributed systems; what you really get is 'at-least-once delivery with at-most-once side effect via deduplication.'

Mental model. Think of HTTP — HyperText Transfer Protocol as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does HTTP — HyperText Transfer Protocol mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose HTTP — HyperText Transfer Protocol, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.