HTTP

HTTP is the set of rules that lets a client and a server talk over a network. When you type systemdesign.academy into a browser, the browser opens a connection to the server and sends an HTTP request. The server reads it, does some work, and sends back an HTTP response. That round trip is the whole protocol in one sentence.

Every request carries a method, a path, headers, and an optional body. The method says what you want to do: GET to read a resource, POST to create one, PUT to replace, PATCH to update part of it, DELETE to remove it. The path points at the resource, like /api/lessons/http. Headers carry metadata such as Content-Type, Authorization, and Cookie.

Every response carries a status code and usually a body. Codes are grouped: 2xx means success (200 OK, 201 Created), 3xx means redirect (301, 304 Not Modified), 4xx means the client made a mistake (404 Not Found, 401 Unauthorized, 429 Too Many Requests), and 5xx means the server failed (500 Internal Server Error, 503 Service Unavailable).

HTTP runs on top of a transport layer. In HTTP/1.1 and HTTP/2 that transport is TCP, usually wrapped in TLS for HTTPS on port 443. HTTP/3 changed this by running over QUIC, which is built on UDP, to cut the handshake time and avoid head-of-line blocking when one packet is lost.

The defining trait of HTTP is that it is stateless. The server does not remember that you logged in two requests ago. To carry identity across requests, the client resends proof every time, normally a session cookie or a bearer token in the Authorization header. State lives in the database or a cache like Redis, not in the protocol.

Performance has improved version by version. HTTP/1.1 added persistent connections so a single TCP connection could serve many requests, but they still went one at a time per connection. HTTP/2 added multiplexing, so many requests share one connection in parallel, plus header compression. HTTP/3 over QUIC removes the TCP head-of-line blocking problem entirely and resumes connections faster on flaky mobile networks.

HTTP is the default for almost any client-to-server communication on the web: loading pages, calling REST and GraphQL APIs, fetching images from a CDN. It is text-based and human-readable, every language has a client, and proxies, load balancers, and caches all understand it, which makes it easy to operate and debug.

The trade-offs come from the request-response model. HTTP is pull-based: the client has to ask before the server can send anything. That makes it a poor fit for real-time push, like live chat or stock tickers, where you want WebSockets or Server-Sent Events instead. The statelessness that makes it scalable also means you pay to reattach identity and context on every call.

Caching is where HTTP shines and where teams get the most wins. Response headers like Cache-Control, ETag, and Last-Modified let browsers and CDNs reuse responses without hitting your origin. A 304 Not Modified response sends no body at all, which is why a well-tuned site can serve most traffic from cache and only touch the database for the parts that actually changed.

Open developer tools and load any page, and you watch HTTP at work. The browser sends GET / with an Accept header, the server returns 200 OK with HTML, and the browser then fires dozens more GET requests for CSS, JavaScript, fonts, and images, many of them answered straight from cache with a 304.

When you log in, the browser sends POST /login with your credentials in the body. The server validates them and replies with Set-Cookie. From then on every request automatically includes that cookie in a Cookie header, which is how the stateless server recognizes you. If the cookie expires, the next protected request comes back 401 and you are bounced to the login page.

Cloudflare and Fastly sit in front of millions of sites and answer HTTP requests at the edge, returning cached responses in single-digit milliseconds and only forwarding a miss to the origin. That entire content delivery layer is built on reading HTTP methods, paths, and cache headers.