What really happens between a click and a reply?

1) The browser parses the URL and checks its caches. 2) DNS: browser/OS cache, then a recursive resolver, which (if not cached) asks root → TLD → authoritative servers and returns an IP with a TTL. 3) TCP three-way handshake (SYN, SYN-ACK, ACK) to port 443. 4) TLS 1.3 handshake, one round trip, which also checks the server's certificate. 5) HTTP request; the server (often behind a CDN and load balancer) replies. 6) The browser parses HTML and fetches CSS, JS and images, reusing the connection.

Number: a fresh HTTPS connection over TCP + TLS 1.3 costs 3 round trips before the first byte, so about 450 ms on a 150 ms ocean link. Follow-up: "How would you make it faster?" → CDN, connection reuse, HTTP/3, DNS prefetch.

TCP is connection-based and gives a reliable, ordered byte stream with flow and congestion control. UDP sends independent datagrams with no handshake, no ordering and no resend; its header is only 8 bytes vs TCP's 20+.

Use TCP for web, APIs, databases, file transfer: anything where every byte matters. Use UDP for DNS lookups, live voice and video, games: anything where late data is useless, or where the app builds its own reliability on top, like QUIC does for HTTP/3.

Per RFC 9110: GET, HEAD, OPTIONS, TRACE (the safe ones) plus PUT and DELETE are idempotent. POST is not; PATCH is not either (RFC 5789).

It matters because networks fail mid-request. If a request is idempotent, the client, a proxy or a load balancer can retry it after a timeout without changing the outcome. For POST we add an idempotency key to get the same guarantee.

Note: idempotent means the same effect, not the same response. A second DELETE can return 404, and that is fine.

401: not authenticated (no or bad credentials). 403: authenticated but not allowed. 404: resource does not exist (also used to hide existence from unauthorised users). 409: conflicts with current state, such as a version mismatch or duplicate. 429: too many requests, rate limited; send Retry-After (RFC 6585). 503: service temporarily unavailable or overloaded; also often with Retry-After.

Why it matters: clients decide whether to retry by code. 4xx means "fix your request, do not retry as-is" (except 429). 5xx and 429 mean "retry later with backoff".

A maps a name to an IPv4 address; AAAA to an IPv6 address (RFC 3596); CNAME makes a name an alias of another name, so the resolver follows it. TTL is how many seconds resolvers may cache the answer.

Trade-off: a short TTL (say 60 s) lets you fail over or migrate quickly but means more DNS queries; a long TTL (hours) means fewer lookups but slow changes. A CNAME cannot sit at the zone apex because RFC 1034 forbids other data next to a CNAME, and the apex must hold SOA and NS records.

HTTP/1.1 is text and handles one request at a time per connection, so browsers open several connections. HTTP/2 (RFC 9113) uses binary frames and multiplexes many streams on one TCP connection, with HPACK header compression. But one lost TCP packet still stalls every stream, as RFC 9113 itself admits.

HTTP/3 (RFC 9114) runs over QUIC on UDP. QUIC orders data per stream, so a loss only delays its own stream; it merges the transport and TLS 1.3 handshakes (1 RTT, 0-RTT on resume); and connection IDs let a connection survive switching from Wi-Fi to 4G. The HTTP semantics (RFC 9110) are the same in all three.

Cursor. The feed is huge and new posts arrive constantly. With offset, page 2 shifts when new posts land at the top, so users see duplicates or miss items, and deep offsets get slow because the database still reads all skipped rows (PostgreSQL's docs say so).

With a cursor I return an opaque next_cursor that encodes the last item's sort key, e.g. (created_at, id), and query WHERE (created_at, id) < cursor ORDER BY ... LIMIT 20 on an index. Every page costs the same. Trade-off: no jumping to page 50, which a feed never needs.

Make additive changes without a version bump (new optional fields, new endpoints) and require clients to ignore unknown fields. Breaking changes (removing or renaming a field, changing types or meanings) get a new version.

Common options: version in the path (/v2/), simple and easy to route; or in a header, like Stripe's dated Stripe-Version, where each account is pinned to the version it started on and can upgrade per request. I would publish a deprecation timeline, log which clients still call old versions, and translate old requests at the edge so the core runs one model.

Client sends Idempotency-Key (a UUID). Server: 1) insert (key, account, request_hash, status=in_progress) with a unique constraint; if it already exists and is done, return the stored response; if in progress, return 409; if the hash differs, return an error (Stripe does this). 2) Do the charge and store the response in the same DB transaction as the business write. 3) Expire keys after, say, 24 hours (Stripe prunes keys at least 24 hours old).

Edge cases: crash between charge and save (do both in one transaction, or make the downstream call idempotent too with the same key), and scoping keys per account so users cannot collide.

REST for public APIs: every language and tool speaks it, and GET responses cache well in CDNs and browsers. gRPC for internal service-to-service calls: protobuf contracts generate typed clients, binary messages are small, it supports streaming and deadlines, and it runs on HTTP/2. But browsers need gRPC-Web via a proxy. GraphQL for client-driven apps that combine data from many services: one round trip, exact fields; the costs are harder caching, N+1 resolver queries and the need for query-cost limits.

A common real setup: GraphQL or REST at the edge, gRPC inside.

Short polling: client asks every N seconds; simple but wasteful and up to N seconds late. Long polling: the server holds the request until there is data or a timeout; near real-time, works anywhere, but reconnect gaps and one held request per user. SSE: one streaming HTTP response, server to client only, built-in reconnect with Last-Event-ID; limited to 6 connections per browser and domain on HTTP/1.1 (MDN). WebSocket: full-duplex after an HTTP 101 upgrade; best for chat and games but stateful, so load balancing and reconnect logic are on you.

Rule: server-push only → SSE; both directions → WebSocket.

TLS 1.2's full handshake takes two round trips. TLS 1.3 sends the client's key share in the first message, so the full handshake takes one round trip (RFC 8446 §2). On a 150 ms link that saves 150 ms per new connection.

0-RTT lets a returning client send data in its very first flight using a saved key. The risk is replay: an attacker can resend that early data, and the server may process it twice. So only idempotent requests like GET should be allowed in 0-RTT, never "transfer money".

Only if the operation is idempotent, or made idempotent with a key. A timeout means "unknown outcome": the server may have done the work.

How: exponential backoff with jitter (random spread, so a million phones do not retry at the same instant), a cap on attempts, respect Retry-After on 429/503, and a total deadline. Retry 5xx and network errors; do not retry most 4xx. Server side: rate limits and load shedding so retries cannot cause a retry storm. Number to quote: without jitter, a short outage can synchronise every client into waves of traffic at the same second.

Connections are long-lived and stateful. Problems: 1) A message for user B may arrive at node 3 while B is connected to node 17, so you need a pub/sub layer (Redis pub/sub, Kafka) or a "user → node" registry to route it. 2) Load becomes uneven: new nodes get no old connections, so rebalancing needs draining. 3) Deploys and crashes drop thousands of connections at once, causing a reconnect storm; add jittered reconnects. 4) The LB must allow long idle times and the HTTP upgrade, and use heartbeats so dead connections are noticed.

Follow-up: "How many connections per node?" → depends on memory per connection; measure, do not guess.

Caching at many layers: the browser, the OS, the recursive resolver, and any middle resolvers each keep the old answer until its TTL expires. If the old TTL was 24 hours, some resolvers can hold it for up to a day. Some resolvers and apps also ignore or clamp TTLs, and long-lived connections (keep-alive, HTTP/2, pooled DB connections) keep talking to the old IP without a new lookup at all.

Fix: lower the TTL well before the change (at least one old TTL ahead), keep the old server running and proxying for a while, and drain long-lived connections. For instant failover, use an IP that does not change (anycast or a load balancer) instead of DNS.

This is the N+1 problem: one query for the users, then the orders resolver runs once per user, one query each. GraphQL resolvers are per field, so this happens naturally.

Fix: batch per request with a DataLoader: collect all 50 user IDs during one tick and run SELECT * FROM orders WHERE user_id IN (...) once, then hand each user its orders. That is 2 queries instead of 51. Also add per-request caching, query depth and complexity limits so a client cannot ask for friends-of-friends-of-friends, and persisted queries to allow CDN caching.

Use PUT /posts/{id}/likes/{userId} to like and DELETE the same URL to unlike. Both are idempotent, so double taps and retries are harmless, with no idempotency key needed. Return 204. Read the count via GET /posts/{id} with like_count, served from a cache.

Scale: likes are write-heavy for viral posts, so store the (post, user) pair as the source of truth and update counters asynchronously through a queue, possibly sharded counters for hot posts. Clients can show the like immediately (optimistic UI). Return 429 with Retry-After if a client floods. Follow-up: "Exact counts?" → eventually consistent counts are fine for likes.

Data only flows server → client, so I pick SSE (or WebSocket if the app already has one). Score events go from the ingest service into a pub/sub topic per match. A fleet of stateless-ish "edge push" servers subscribe to topics and fan out to their connected viewers; clients connect via a load balancer and reconnect with Last-Event-ID so they do not miss scores.

Sizing: at an assumed 50k connections per server, 5M viewers need about 100 servers plus headroom. Updates are tiny and rare (a few per minute), so bandwidth is small; the hard part is connection count and reconnect storms after deploys (drain gradually, jittered reconnect). Fallback for old clients: polling a CDN-cached JSON every few seconds, which is cheap because every viewer gets the same answer.