Skip to main content

HTTP/HTTPS

HTTP (HyperText Transfer Protocol) is the application-layer protocol — the top of the OSI Model — that almost every web and API request in a system design interview ultimately runs on. It defines a simple request/response contract: a client sends a request with a method, a path, headers, and optionally a body; a server sends back a status code, headers, and optionally a body. HTTPS is that same protocol wrapped in TLS encryption, so the content of every request and response is unreadable to anything sitting on the network path between client and server.

HTTP is stateless — on purpose​

Each HTTP request is handled independently; the server isn't required to remember anything about a client's previous request. This is a deliberate design choice, not an oversight: statelessness is what makes it trivial to route any request to any server behind a load balancer — there's no session data pinning a client to a specific machine. The tradeoff is that anything resembling a login session or shopping cart has to be reconstructed on every request, typically via a cookie or token the client sends back each time that a server (or shared store) can look up. This exact tension — statelessness enabling horizontal scaling, at the cost of needing to externalize state — comes up again in Stateful vs. Stateless Design.

Why HTTPS is the default, not an option​

Plain HTTP sends everything — headers, cookies, request bodies — in cleartext, readable by any router, ISP, or attacker positioned anywhere on the path. HTTPS adds a TLS handshake before any HTTP data is exchanged, during which the client and server agree on encryption keys and the server proves its identity via a certificate signed by a trusted authority.

System Design Lab

That handshake isn't free — it's extra round trips before any real data moves, which is a direct cost against the latency budget of every new connection. TLS 1.3 cut this from two round trips down to effectively one (and supports zero-round-trip resumption for a client that's connected before), specifically because that handshake cost was significant enough at internet scale to justify redesigning the protocol around reducing it. Even with that overhead, HTTPS is treated as non-negotiable today: browsers flag plain HTTP as "not secure," search engines rank it lower, and any request carrying credentials, tokens, or personal data over plaintext HTTP is a straightforward security failure.

HTTP/1.1 → HTTP/2 → HTTP/3​

TransportKey change
HTTP/1.1TCPOne request waits its turn per connection (or needs many parallel connections)
HTTP/2TCPMultiplexes many requests over a single connection — no more juggling parallel connections
HTTP/3QUIC (over UDP)Multiplexes over QUIC instead of TCP, so one lost packet only stalls its own stream, not every request sharing the connection

HTTP/2's multiplexing fixed application-level head-of-line blocking (requests no longer had to queue behind each other on the same connection), but a single lost packet still stalled every stream on the connection, because TCP itself guarantees strictly ordered delivery — see TCP vs UDP. HTTP/3 fixes that remaining problem by moving off TCP entirely onto QUIC, a transport protocol built on UDP that manages its own per-stream reliability. It's a good concrete example of a protocol reaching back down a layer to solve a problem the layer below it was quietly causing.

Methods and status codes, briefly​

HTTP methods (GET, POST, PUT, DELETE, ...) and status code conventions are foundational, but they're covered in depth where they actually drive design decisions — see APIs and REST vs. GraphQL. The one habit worth building now: state the method and status code explicitly when describing an API interaction in an interview ("the client sends a POST and gets back a 201") — it's more precise than "the client saves the data," and it signals you're thinking in terms of the actual protocol contract.

HTTPS everywhere: pros and cons​

Pros

  • Encrypts requests and responses end-to-end, protecting credentials, tokens, and data in transit
  • Authenticates the server's identity via its certificate, preventing simple impersonation
  • Now effectively required for SEO, browser trust indicators, and most modern web APIs

Cons

  • Adds handshake round trips and CPU cost for encryption/decryption on every connection
  • Requires certificate provisioning, renewal, and rotation as ongoing operational work
  • Terminating TLS centrally (e.g. at a reverse proxy) means that component now holds sensitive key material

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.