HTTP and HTTPS

For this lesson, we'll cover request anatomy, the method and status code semantics interviewers probe, caching headers, HTTP/1.1 vs 2 vs 3, what TLS 1.3 costs, certificates, and where TLS ends in a design. Every diagram you draw has arrows labelled "HTTPS", and the follow-ups ("is that retry safe?", "which status code?", "where's TLS terminated?") separate people who've run services from people who've only called them.

01Request and response anatomy

Every later topic is a header or a status code on this shape. Here's a conditional GET and its answer, written the HTTP/1.1 way (HTTP/2 and HTTP/3 carry the same fields in binary frames).

GET /v1/orders/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...
Accept: application/json
If-None-Match: "v7"

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=60
ETag: "v8"
Content-Length: 87

{"id": 42, "status": "SHIPPED", "total": 1299, "currency": "INR", "updatedAt": "2026-10-20T09:12:00Z"}

Notice three things:

• The first line is the verb and the target: method, path, version. The response's first line is the status.
• Headers carry the metadata: who you are (Authorization), what you accept, and caching hints. The server didn't match the client's If-None-Match: "v7", so it sent the full body with a new ETag.
• HTTP is stateless. Each request carries everything the server needs. Sessions, logins and carts are built on top with cookies or tokens, which is what lets you put any server behind a load balancer.

02Methods: safe, idempotent, cacheable

RFC 9110 gives every method properties, and these are what a retrying client, a proxy and a cache rely on. Safe means the client isn't asking for any state change. Idempotent means sending it twice has the same intended effect as sending it once.

The column that matters in design interviews is Idempotent. RFC 9110 lets a client or proxy automatically retry an idempotent request after a dropped connection, and says a proxy must not automatically retry a non-idempotent one. So when a payment POST times out, nobody can safely resend it unless you add an idempotency key. The API design article goes deeper on choosing methods for resources.

03Status codes that come up in design interviews

You need these, and a reason for each.

The split I want to hear: 4xx means "don't retry the same request", 5xx and 429 may be worth retrying with backoff, and 502/503/504 usually come from the proxy in front of your service. Retry policy lives in fault tolerance.

04Caching headers: Cache-Control and ETag

HTTP has caching built in (RFC 9111), and in a read-heavy design these headers are free capacity.

• Cache-Control: max-age=N: fresh for N seconds; reuse without asking. s-maxage overrides it for shared caches like a CDN.
• no-cache: you may store it, but must revalidate before each use. It does not mean "don't cache".
• no-store: never store it. Use for secrets and personal data.
• private vs public: only the user's browser may store it, vs CDNs and proxies too.
• ETag plus If-None-Match: a version tag. If it still matches, the server answers 304 with no body, which saves bandwidth but still costs a round trip.

My defaults: hashed static assets get public, max-age=31536000, immutable (a year), a product page gets a short s-maxage, a user's order gets private with an ETag. ETags also power optimistic locking with If-Match, covered in the API design article; the CDN side is in CDN.

05HTTP/1.1 vs HTTP/2 vs HTTP/3

Same methods, headers and status codes in all three; what changes is how bytes are carried.

Header compression matters because an API call can carry a kilobyte of cookies and tokens; HPACK and QPACK send repeats as small table references. HTTP/2 is the default at the edge and for gRPC; HTTP/3 pays off on mobile and lossy networks (TCP vs UDP explains why).

06HTTPS: what TLS 1.3 costs

TLS gives you three things: encryption (nobody on the path can read it), integrity (nobody can change it unnoticed) and authentication (the certificate proves the server's identity). The cost is a handshake, and the figure shows exactly where it sits.

TCP's handshake is the first round trip. In the second, the client sends its ciphers and a key share, and the server replies with its key share, certificate and Finished; both sides now have keys, and the client's Finished travels with the first request. TLS 1.2 needed two round trips for this.

0-RTT is the shortcut for a client that has talked to this server before: it uses a pre-shared key from the last session to encrypt the request in its very first flight. RFC 8446 is explicit that this early data isn't forward secret and has no replay protection across connections. An attacker who captures it can send it again, so 0-RTT must only carry requests that are safe to repeat.

Certificates and the chain of trust

A certificate binds a public key to names like api.example.com, and it's signed by a certificate authority. The client doesn't know your certificate, but it does trust a small set of root CAs shipped with the OS or browser, so it walks the chain.

Roots stay offline and sign intermediates (Let's Encrypt issues subscriber certificates only from intermediates). If the server forgets the intermediate, browsers often paper over it with cached copies while a Java service fails the handshake.

07Where TLS terminates in a design

"Terminating TLS" means the hop where traffic is decrypted. It decides who sees plaintext, where certificates live and what can be cached.

My default: terminate at the CDN or load balancer close to users, so the handshake round trips are short and the edge can cache, compress and route on paths. Inside, re-encrypt with mTLS when the network isn't trusted or a security policy demands it; a service mesh makes that cheap to operate. Pass-through (an L4 balancer forwarding encrypted bytes) is for when the backend must hold the key, and you give up path routing and caching. The proxy side is covered in Proxy vs reverse proxy.

08Keep-alive and connection reuse

HTTP/1.1 connections are persistent by default, and HTTP/2 and HTTP/3 multiplex many requests on one connection. The point of both is to pay the TCP and TLS handshakes once and then send requests at one round trip each.

My rough arithmetic: a new connection costs 2 RTT of setup (160 ms) before the 80 ms request, so two thirds of each 240 ms call is handshake, and the inventory service does 3,000 full handshakes a minute. With a pool, handshakes happen once per connection lifetime and calls drop to about 80 ms. In Spring, that's a client built once, with explicit timeouts:

@Bean
RestClient inventoryClient() {
    HttpClient jdk = HttpClient.newBuilder()
            .connectTimeout(Duration.ofSeconds(2))      // TCP + TLS setup must finish in 2 s
            .version(HttpClient.Version.HTTP_2)          // falls back to HTTP/1.1 if the server can't
            .build();                                    // the JDK client pools connections itself
    var factory = new JdkClientHttpRequestFactory(jdk);
    factory.setReadTimeout(Duration.ofSeconds(3));       // waiting for the response
    return RestClient.builder()
            .baseUrl("https://inventory.internal")
            .requestFactory(factory)
            .build();
}

Notice the bean is a singleton: a new client per request throws the pool away. The two timeouts differ on purpose: a slow connect usually means the host is down, a slow read means it's busy. This needs Spring Framework 6.1+.

09Trade-offs and failure modes

10How it shows up in design problems

• Design a URL shortener: 301 vs 302 is a real decision. Browsers cache a 301, which saves load but means repeat clicks may never reach you to be counted; a 302 keeps every click visible at the cost of more traffic.
• Design a payment system: POST with an idempotency key, 409 for conflicting state, 202 for asynchronous settlement, TLS everywhere, no 0-RTT on writes.
• Design a rate limiter: 429 plus Retry-After and rate-limit headers are the client-facing contract.
• Design an LLM gateway: long-running streaming responses mean read timeouts per route, not one global value, and connection pools to each upstream provider.

11Follow-up questions

What if a mobile client on a flaky network sends a POST and the connection drops before the response?

The client can't know whether the server processed it. With HTTP/1.1 or HTTP/2 over TCP, the safe answer is an idempotency key in a header so a retry returns the original result instead of creating a second order. HTTP/3 helps the network part (connection migration, fewer stalls), not the "did it happen?" part.

What if we moved everything to HTTP/2: does head-of-line blocking go away?

At the HTTP layer, yes: one slow response no longer blocks the next on the same connection. At the TCP layer, no: all streams share one byte stream, so one lost packet stalls them all, and on lossy links HTTP/2 can do worse than several HTTP/1.1 connections. Removing that is what HTTP/3 is for.

What if security asks for end-to-end encryption, but we need the load balancer to route on paths?

Then the load balancer must decrypt: terminate TLS there and open a new TLS (ideally mTLS) connection to the backend. Every hop is encrypted; only the load balancer and the service see plaintext. True pass-through means accepting L4 routing.

What if a certificate expires at 2 a.m.?

Every validating client fails the handshake, so it's a full outage for that hostname, and no cache helps because the handshake comes before any request. Automate renewal (ACME) well before expiry and alert on days remaining.

12How to say it in the interview

When I ask about HTTP in a design, I'm listening for three things: that your methods and status codes tell a retrying client what's safe, that you know what a new HTTPS connection costs and avoid paying it per request, and that you can say where TLS starts and stops.