System design · Module 06 of 29 · Level 2: Building blocks

Networking and protocols: TCP, UDP, QUIC and the HTTP versions

Module 01 followed one request. This module opens the boxes it passed through: what each network layer promises, why TCP's guarantees sometimes hurt, how HTTP/2 and HTTP/3 fix different problems, and what DNS can do beyond turning names into addresses. You'll use these ideas whenever you choose a protocol for real-time updates, place a load balancer, or wonder why mobile users see slow pages.

New to this?Start with B3 · Networks in plain terms in Level 0; this module assumes it.

1. The idea

Sending data is like shipping goods. IP is the road network: it gets a truck to the right town, mostly, with no promises. TCP is a courier that numbers every box, waits for signed receipts and re-sends anything lost, and hands boxes over strictly in order. UDP is dropping boxes at the depot and hoping. QUIC is a modern courier that tracks each customer's order separately, so one lost box doesn't hold up everyone else's.

Networks are built in layers. Each one uses the layer below and adds a promise. Only three matter day to day:

Layer	Examples	What it promises
L3 Network	IP (IPv4, IPv6)	Gets a packet (up to about 1,500 bytes on most links) towards an address. Best effort: packets can be lost, duplicated or reordered.
L4 Transport	TCP, UDP, QUIC	Connects two programs (by port). TCP adds reliability, order and congestion control; UDP adds almost nothing; QUIC adds TCP-like reliability per stream, plus encryption.
L7 Application	HTTP, gRPC, WebSocket, DNS	The messages your code understands: requests, responses, frames.

"L4" and "L7" come from the seven-layer OSI model; you'll hear them most about load balancers. An L4 load balancer forwards connections by IP and port without reading them. An L7 one reads the HTTP request and can route by path, header or cookie (Module 08).

TCP's promises, and their price

Connection setup: a three-way handshake (one round trip) before data.
Reliability: the receiver acknowledges data; anything not acknowledged in time is sent again.
Order: bytes are delivered to your program in the order sent. If one packet is lost, everything after it waits until it's re-sent. This is head-of-line blocking.
Flow and congestion control: TCP starts slowly and speeds up while the network copes (slow start), and backs off when packets are lost. Fair and safe, but a new connection can't use the full link at once.

UDP skips all of it: no handshake, no retries, no order. You send a datagram; it arrives or it doesn't. That's ideal when late data is useless (a video call frame, a game position) or when the request is a single small packet (DNS).

2. How it works

Head-of-line blocking, three ways

A browser loads three files (A, B, C), each three packets long, from a server 50 ms away. Packet A2 gets lost. Press Play to compare what each HTTP version does.

How many round trips before the first byte?

Stack	Setup before the request can be sent	Round trips
TCP + TLS 1.2	TCP handshake, then a two-round-trip TLS handshake	3
TCP + TLS 1.3	TCP handshake, then a one-round-trip TLS handshake	2
QUIC (HTTP/3)	Transport and TLS 1.3 handshakes combined	1
QUIC resumption (0-RTT)	Request sent with the first packet to a server seen before	0

0-RTT data can be replayed by an attacker who captures it, so servers only accept it for requests that are safe to repeat (idempotent GETs).

DNS is more than a phone book

Record types: A (IPv4 address), AAAA (IPv6), CNAME (an alias for another name), MX (mail), TXT (verification, email policy), NS (which servers are authoritative).
TTL: how long resolvers may cache an answer. Short TTLs (30–60 s) let you move traffic quickly but mean more lookups; long TTLs are cheap but slow to change.
Routing with DNS: return different addresses by the user's location (GeoDNS), by measured latency, or by weight (send 5% to a new region). Health checks can stop returning a dead region's address, within the TTL.
Anycast: many servers around the world share one IP address, and the internet's routing sends each user to the nearest. CDNs and public DNS resolvers (1.1.1.1, 8.8.8.8) work this way.

Ports, NAT and private networks

A machine has one IP address but many programs, so connections are identified by (source IP, source port, destination IP, destination port). Inside a cloud, servers sit in a private network (a VPC) with private addresses; the internet reaches them only through a load balancer or gateway. Outbound traffic goes through NAT, which shares a few public addresses among many machines. NAT is also why two phones can't easily connect to each other directly (Module 19 covers WebRTC's workaround).

3. Try it yourself

Packet loss and page load

Thirty small files from a server, with some packet loss (mobile networks commonly see 1–2%, bad ones much more). Compare the HTTP versions as loss rises.

Model: 30 files of 3 packets each. HTTP/1.1 uses 6 parallel connections, each fetching files one after another; HTTP/2 multiplexes all files over one TCP connection, so every lost packet stalls all of them for a round trip; HTTP/3 multiplexes over QUIC, so a loss stalls only its own file. Real browsers and networks are more complex, but the shape matches published measurements.

Choose the transport

4. Trade-offs

TCP: the safe default

Reliable, ordered, supported everywhere, understood by every load balancer and firewall. Its costs (handshake, head-of-line blocking, slow start) matter mostly on long or lossy paths.

UDP: speed with no safety net

You build only the reliability you need. Right for real-time media and games; wrong for anything that must arrive complete, unless you're building a protocol (as QUIC did).

HTTP/2 vs HTTP/3

HTTP/2 fixed HTTP/1.1's one-request-at-a-time limit but kept TCP's head-of-line blocking. HTTP/3 fixes that and connects faster, at the cost of UDP traffic some corporate networks block (browsers fall back to HTTP/2).

Long-lived vs short connections

Reusing connections (keep-alive, connection pools) saves handshakes and slow start, but each open connection holds memory on both sides and pins a client to one server, which complicates load balancing.

5. In real systems

Browsers and CDNs negotiate the best version automatically: HTTP/2 over TLS, and HTTP/3 when the server advertises it (with the Alt-Svc header or a DNS HTTPS record). You rarely choose; you enable it on the CDN or load balancer.
Between services inside a data centre, round trips are tiny, so HTTP/1.1 with keep-alive or HTTP/2 (gRPC uses HTTP/2) is the norm. The bigger wins there are connection pools and avoiding long chains of calls.
Real-time media (video calls, cloud gaming) uses UDP-based protocols (RTP inside WebRTC) and tolerates loss with error concealment rather than re-sending.
Databases and caches speak their own binary protocols over TCP (PostgreSQL's wire protocol, RESP for Redis and Valkey). Each connection costs server memory, which is why connection poolers like PgBouncer exist (Module 11).
Specifications: TCP is RFC 9293, QUIC is RFC 9000, HTTP/3 is RFC 9114 and TLS 1.3 is RFC 8446.

The technologies up close

The default answer in an interview"TCP and HTTPS, REST APIs, behind an L7 load balancer, with timeouts and retries using exponential backoff." Say that, and move on. Change any part of it only when the question gives you a reason, and say the reason out loud. Each block below tells you what that reason looks like, and what not to say.

TCP

The default · assume it

A reliable, ordered byte stream between two programs. Nearly everything you design runs on it: HTTP/1.1 and HTTP/2, gRPC, database and cache connections, Kafka.

How it works

Open: a three-way handshake (SYN → SYN-ACK → ACK) costs one round trip before any data.
Send: bytes are numbered; the receiver acknowledges them; anything unacknowledged in time is sent again. The application sees bytes in the order they were sent.
Pace: slow start and congestion control speed up while the network copes and back off on loss.
Close: each side sends FIN and acknowledges the other's. Opening and closing cost time and state on both machines, which is why connections are reused (keep-alive, pools, HTTP/2 multiplexing).

Status today

Universal. Every load balancer, firewall, proxy and library supports it. It isn't going anywhere; HTTP/3 replaces it only for some browser traffic.

Use it when

Data must arrive complete and in order: APIs, payments, chat messages, file transfers
Service-to-service calls and database connections
Basically always, unless one of the cases on the right applies

Skip it when

Late data is useless: live audio and video, game positions
One tiny request-response where a handshake would dominate (DNS)

In the interview

Don't announce it; it's assumed. Mention it only when you justify UDP somewhere else, or when connection cost matters: Each client keeps one long-lived connection, so we pay the handshake once.

🚩 Red flags

Calling TCP "slow" and choosing UDP for data that must arrive. You'd have to rebuild retries, ordering and congestion control yourself.
Treating a TCP acknowledgement as proof the request was processed. It only means the bytes reached the other machine; the app can still crash. That's why APIs need idempotency keys and application-level acks.
Opening a new connection per request in a high-traffic design without noticing the handshake cost.

UDP

Situational · real-time media and games

Send a datagram; it arrives or it doesn't. No handshake, no retries, no ordering, no congestion control. Applications add only the reliability they need.

How it works

Each datagram is independent and fits in one packet. Loss, duplicates and reordering are the application's problem. Real-time apps handle loss by sending the latest state instead of re-sending old state (a game sends positions 30 times a second), or by hiding gaps (audio codecs conceal a missing 20 ms frame).

Status today

Mature and everywhere, but browsers can't open raw UDP sockets. Web clients reach UDP only through WebRTC (calls, Module 19) or HTTP/3. Some corporate networks block or throttle UDP.

Use it when

Live voice and video, cloud gaming, multiplayer game state
DNS lookups
High-volume telemetry where losing a few points is fine (StatsD-style metrics)

Skip it when

Anything that must arrive: messages, orders, uploads
Web clients, unless you go through WebRTC, with a TCP fallback

In the interview

Raise it only for real-time media or games, and say what you do about loss: Positions go over UDP 30 times a second; a lost update is replaced by the next one, so we never re-send.

🚩 Red flags

"UDP because it's faster" for a chat app or a feed. The interviewer will ask what happens to a lost message.
Forgetting that browsers can't speak raw UDP.
Choosing UDP but not explaining how the app copes with loss, duplicates and reordering.

QUIC and HTTP/3

Mature · rarely needed in interviews

QUIC is a transport protocol that runs on top of UDP and rebuilds what TCP gives you (reliability, ordering, congestion control) with three changes: TLS 1.3 encryption is built in, each stream is ordered separately, and a connection has its own ID rather than being tied to an IP address. HTTP/3 is HTTP running over QUIC.

How it works

Faster setup: the transport and TLS handshakes are combined, so a new connection needs one round trip instead of TCP + TLS 1.3's two. To a server it has seen before, a client can send a request in its very first packet (0-RTT), but only for requests that are safe to repeat, because an attacker could replay that packet.
No head-of-line blocking between streams: a lost packet delays only its own stream (the scene at the top of section 2).
Connection migration: when a phone moves from Wi-Fi to mobile data its IP address changes. A TCP connection dies and must reconnect; a QUIC connection carries on, because it's identified by its connection ID.
Runs in user space: QUIC is implemented in libraries, not the operating system kernel, so it evolves quickly, but it typically costs more CPU per byte than TCP.

Status today (checked October 2026)

Standardised in 2021–2022: QUIC is RFC 9000, HTTP/3 is RFC 9114.
Supported by default in Chrome and Edge (since 87), Firefox (88) and Safari (16): about 95% of browsers in use, per caniuse.
About 41% of websites offer HTTP/3 (W3Techs), and about 21% of the requests Cloudflare saw in 2025 used it, against 50% for HTTP/2 (Cloudflare Radar).
You usually switch it on at the CDN or load balancer; browsers discover it through the Alt-Svc header or a DNS HTTPS record and fall back to HTTP/2 when UDP is blocked. Inside data centres, TCP still dominates.

Use it when

Mobile users on lossy or changing networks (a feed with many images, video start-up)
Users far from your servers, where saved round trips matter
You already have a CDN: enabling HTTP/3 there is usually a setting

Skip it when

Service-to-service traffic inside a data centre: round trips are tiny and tooling assumes TCP
Networks that block UDP (you'll need the HTTP/2 fallback anyway)
The question is about anything other than the client's network

In the interview

Default to HTTPS and don't name a version. If the interviewer asks about mobile performance or poor networks, one sentence is enough: We'd enable HTTP/3 at the CDN: QUIC avoids TCP's head-of-line blocking and survives network switches, and clients fall back to HTTP/2. Then return to the design.

🚩 Red flags: why not to bring it up unprompted

It rarely changes the design. QUIC is a setting on the CDN, not a box on your diagram. Time spent on it is time not spent on the data model or the deep dives that are actually scored.
Mentioning it invites follow-ups. Raise it only if you can answer these confidently: How does it avoid head-of-line blocking? Why is 0-RTT only for idempotent requests? What happens when UDP is blocked? Why does a connection survive a network change? If you can't, it costs you more than it earns.
Using it for the wrong hop. "Our microservices talk over QUIC" signals chasing novelty: inside a data centre it buys almost nothing.
Getting the layers wrong. QUIC is a transport running on UDP; it's not "UDP with no reliability", and HTTP/3 isn't a different API style from REST.

HTTP and HTTPS

The default · always HTTPS

HTTP is the request-response protocol your APIs speak: a method, a path, headers and a body; a status code, headers and a body back. HTTPS is HTTP inside TLS.

How it works

Stateless: each request carries everything needed (including the auth token), so any server can handle it. Keep as much of your system stateless as you can.
Methods: GET reads and never changes anything; POST creates; PUT replaces; PATCH partly updates; DELETE removes. GET, PUT and DELETE are idempotent; POST isn't unless you add an idempotency key (Module 07).
Status codes: 2xx worked (200, 201) · 3xx go elsewhere (301, 302, 304) · 4xx the caller must change something (400, 401 not signed in, 403 not allowed, 404, 429 rate-limited) · 5xx our fault (500, 502 bad gateway, 503).
HTTPS (TLS): encrypts traffic and proves the server's identity. It's usually terminated at the load balancer or CDN, and internal traffic is re-encrypted where policy requires it.
Versions: HTTP/1.1 (one request at a time per connection), HTTP/2 (many requests multiplexed on one TCP connection), HTTP/3 (over QUIC). The semantics are identical across all three.

Status today

HTTPS is the norm: browsers warn on plain HTTP, and HTTP/2 or HTTP/3 carry most browser traffic. Plain HTTP survives only inside private networks, and even there it's increasingly encrypted.

Use it when

Every client-facing API (REST over HTTPS is the default)
Most internal APIs, including gRPC, which runs on HTTP/2

Skip it when

The server must push often (consider SSE or WebSockets, Module 19)
Real-time media (WebRTC over UDP)

In the interview

Say REST over HTTPS once, then use methods and status codes correctly in your API. Take identity from the token: The user ID comes from the auth token, never from the request body.

🚩 Red flags

Trusting a user ID in the request body. HTTPS stops eavesdroppers, not the client: anyone can send any body they like. Identity comes from the authenticated token, and every input is validated.
A GET that changes data, or an error hidden inside a 200 response.
Mixing up 401 (who are you?) and 403 (you're not allowed).

The eight fallacies of distributed computing

The mindset · assume the opposite

Eight assumptions newcomers make about networks, all false. Designs that rely on any of them fail in production.

How it works

The network is reliable → retries, idempotency, timeouts.
Latency is zero → fewer round trips, batching, caching near users.
Bandwidth is infinite → compress, paginate, send IDs not blobs.
The network is secure → TLS everywhere, authenticate every call.
Topology doesn't change → service discovery, no hard-coded addresses.
There is one administrator → many teams and providers, each with their own changes.
Transport cost is zero → serialisation and egress cost CPU and money.
The network is homogeneous → different clients, protocols and versions.

Status today

Listed by Peter Deutsch and colleagues at Sun Microsystems in the 1990s; still the best one-page checklist for reviewing a design.

Use it when

Reviewing any arrow on your diagram: what if this call fails, is slow, or is attacked?

Skip it when

Reciting the list; apply it to your own arrows instead

In the interview

This call crosses the network, so it gets a timeout, retries with backoff, and an idempotency key.

🚩 Red flags

Drawing arrows as if they always succeed instantly. The interviewer's next question will be "what if it doesn't?"

RPC: why a remote call isn't a local call

The default abstraction · know its limits

Remote procedure call frameworks (gRPC, Thrift, REST clients) make a network request look like a function call. The look is convenient and misleading.

How it works

A local call either returns or throws. A remote call can also time out with an unknown outcome: the server may have done the work and lost the reply (Module 07's retry scene).
It takes milliseconds, not nanoseconds, so chatty loops of small calls are slow (the N+1 pattern).
Arguments are serialised; versions on each side must stay compatible.

Status today

Universal inside companies (gRPC, Thrift, HTTP/JSON clients); service meshes add retries and timeouts around it.

Use it when

Service-to-service calls, with timeouts, retries and idempotency

Skip it when

Pretending it's local: no loops of hundreds of small calls per request

In the interview

If the call times out we don't know whether it happened, so it carries an idempotency key and we retry safely.

🚩 Red flags

Treating a timeout as "it didn't happen" and retrying a payment without a key.

DNS: resolution, caching and failover

The default · usually one sentence

How a name becomes an address, where the answers are cached, and how DNS steers traffic away from failures.

How it works

Resolution: the device's stub resolver asks a recursive resolver (the ISP's, or 1.1.1.1 / 8.8.8.8). On a miss it walks the hierarchy: a root server points to the .com TLD servers, which point to the domain's authoritative servers, which return the address. The recursive resolver does the walking (recursive); each server only refers it onward (iterative).
Caching: every layer (browser, OS, resolver) caches answers for their TTL, so most lookups never leave the first resolver.
Steering and failover: authoritative DNS can answer by location (GeoDNS), latency or weight, and stop returning an unhealthy region's address. Changes take effect only as caches expire (the TTL), and some clients cache longer than told.

Status today

Managed authoritative DNS (Route 53, Cloud DNS, Azure DNS, Cloudflare) with health checks is standard. DNS outages are rare but severe: when a provider's DNS fails, everything behind it disappears.

Use it when

Pointing users at the nearest healthy region
Weighted moves of traffic between regions
A simple first layer of client-side load balancing

Skip it when

Fast failover inside one region (load balancer health checks act in seconds; DNS waits for TTLs)

In the interview

GeoDNS sends users to the nearest region, with health checks and a 60-second TTL so a failed region drains within minutes.

🚩 Red flags

Relying on DNS for instant failover: cached answers keep sending users to the dead region until they expire.
One DNS provider and long TTLs for a critical domain, without saying what happens if it fails.

6. Remember it

Memory hook: "TCP queues the line, QUIC gives each order its own line"TCP delivers everything in order, so one lost packet holds up all that follows. QUIC keeps streams separate, so a loss only delays its own stream.

How this hook works: what "TCP queues the line, QUIC gives each order its own line" means

What the slogan means, phrase by phrase

"TCP queues the line": One ordered byte stream per connection. HTTP/2 puts many requests on that one stream, so a lost packet stalls them all: head-of-line blocking.
"QUIC gives each order its own line": Independent streams inside one connection. A loss in one stream doesn't stop the others.
(what's left unsaid): UDP has no line at all: every packet is on its own, which is exactly what real-time media wants.

Why this picture fits: everyone has stood behind one slow customer at a single checkout. Opening a lane per customer is HTTP/3's idea.

The story → the concept

At the shop	On the network
One checkout, one queue	One TCP connection
Six checkouts, but each serves one customer at a time	HTTP/1.1 with six connections
One checkout scanning many baskets at once	HTTP/2 multiplexing over TCP
A customer whose card is declined holds everyone	A lost packet causing head-of-line blocking
Separate lanes in the same shop	QUIC streams (HTTP/3)

Watch it on an example

A phone on a train loads a feed with 40 thumbnails over HTTP/2, with 3% packet loss.
Each loss stalls all 40 downloads for about a round trip: the feed fills in jerkily.
Over HTTP/3, each loss delays only one thumbnail; the rest appear on time.
When the phone moves from Wi-Fi to mobile data, QUIC's connection ID lets the connection survive the new IP address; TCP would have to reconnect.

The trap it saves you from

Assuming "more parallel requests over one connection" is always better. On lossy links, HTTP/2 can be slower than HTTP/1.1's six separate connections.

It still works when…

You think about message queues: one partition in Kafka is one ordered line too. A single slow message holds up those behind it in that partition, which is why ordering is kept only where it's needed (Module 18).

7. Common mistakes

Choosing UDP for data that must arrivePayments, chat messages and file transfers need every byte. Without TCP or QUIC you'd have to rebuild retries, ordering and congestion control yourself.

Opening a new connection per requestEvery request then pays for handshakes and slow start. Reuse connections with keep-alive and pools, especially to databases.

Relying on DNS for instant failoverClients cache answers for at least the TTL, and some ignore it. Use DNS failover for regions, with load balancers and health checks for fast failover within a region.

Ignoring the path users actually haveBenchmarks from a data centre hide mobile loss and latency. Test with a network link conditioner or browser throttling.

Accepting 0-RTT data for writes0-RTT requests can be replayed. Only allow them for idempotent reads.

8. Design exercise (25 minutes)

See the versions. In your browser's DevTools → Network, right-click the column header and enable "Protocol". Load three big sites. Which use h2, which h3?
Read DNS. Run dig example.com A, dig example.com AAAA and dig www.github.com CNAME. Note the TTLs. Which would you lower before a migration, and to what?
Pick transports. For a multiplayer game: lobby and matchmaking, in-game positions, chat, purchases. Choose TCP, UDP or QUIC for each and justify it in one line.
Throttle. In DevTools, set network throttling to "Slow 4G" and reload a page you work on. Which requests suffer most, and would HTTP/3 or fewer requests help more?
Write it down. The four-row round-trip table from section 2, in your design notebook.

9. Self-check quiz

With HTTP/2 over TCP, what happens when one packet is lost?

TCP delivers bytes strictly in order, so all multiplexed streams stall until the lost packet is re-sent.

How many round trips does a new HTTP/3 connection need before the request is sent?

QUIC combines the transport and TLS 1.3 handshakes into one round trip (zero when resuming, for safe requests).

Which is the best fit for UDP?

A late video frame is useless, so re-sending it is pointless. Low delay matters more than completeness.

You need to send /api/* to one service and /images/* to another. What do you need?

Only a layer-7 balancer reads the HTTP request and can route by path.

You're designing a photo feed. When should you bring up QUIC?

QUIC rarely changes the design: it's a CDN setting. Raise it only when the question is about the client's network, and only if you can answer the follow-ups (head-of-line blocking, 0-RTT replay, UDP blocked).

Where should the API take the caller's user ID from?

HTTPS protects against eavesdroppers, not against the client itself: anyone can put any ID in a body. Identity comes from the verified token.

A call to the payment service times out. What do you know?

The work may be done and only the reply lost. Retry only with an idempotency key.

You remove a failed region from DNS. Why do some users keep reaching it for a while?

Every cache layer keeps the answer for its TTL (and some clients longer), so DNS failover takes at least that long.

10. Go deeper

Resource	Time	Why
High Performance Browser Networking (Ilya Grigorik), chapters on TCP, UDP and HTTP/2	2–3 h	The best explanation of slow start, head-of-line blocking and multiplexing, with diagrams.
HTTP/3 explained (Daniel Stenberg, author of curl)	45 min	A short free book on why QUIC exists and how HTTP/3 uses it.
What is DNS? (Cloudflare Learning Center)	20 min	Resolvers, record types, TTLs and anycast, plainly explained.
Evolution of HTTP (MDN)	15 min	From HTTP/0.9 to HTTP/3 on one page.

11. Under the hood (optional)

How TCP, TLS, HTTP, DNS, load balancers and rate limiters really behave. Not needed for most interviews; open it when you want to know how the products really do it. All the deep dives are listed on the Under the hood page.

Networking, proxies and rate limitingTCP congestion control with a lab, TLS 1.3 details, HTTP versions, DNS records, a CIDR calculator, load-balancing and rate-limiting algorithm labs, 7 products comparedabout 45 min

Most "the network is slow" problems are explained by a handful of mechanisms: how TCP decides how fast to send, what each HTTP version does with a lost packet, how a load balancer picks a server, and how a rate limiter counts. This deep dive works through each with something you can run.

TCP: windows and congestion control

Reliability: every byte has a sequence number; the receiver acknowledges what arrived; missing data is retransmitted after a timeout or after three duplicate ACKs (fast retransmit).
Flow control: the receiver advertises a window, how much it can buffer, so a fast sender can't overrun a slow reader.
Congestion control: the sender keeps its own congestion window (how much may be unacknowledged in flight), starts small and doubles each round trip (slow start), then grows carefully and backs off when it sees loss. Throughput ≈ window ÷ round-trip time, so long-distance links need large windows.
Small-packet traps: Nagle's algorithm holds small writes until the previous one is acknowledged, and delayed ACKs wait to piggyback: together they can add 40–200 ms to chatty request/response traffic, which is why RPC and interactive systems set TCP_NODELAY.
Connection lifecycle: the side that closes first holds the connection in TIME_WAIT (typically 60 s on Linux) so late packets aren't mistaken for a new connection; a proxy opening thousands of short connections can run out of ports, another reason to reuse connections. SYN floods are blunted by SYN cookies, which avoid storing state until the handshake completes.

Compare three congestion-control algorithms on a link that carries 40 packets per round trip, with a 20-packet router buffer:

CUBIC is the Linux default: after a loss it grows along a cubic curve back toward the window where the loss happened, then probes beyond it. BBR (from Google) instead measures the bottleneck bandwidth and minimum round-trip time and sends at that rate, so it doesn't fill buffers and doesn't treat random loss as congestion. Simplified models; real stacks add many refinements.

TLS 1.3 details

Piece	What it does
SNI	The client names the site it wants in the first message, so one IP can serve many certificates (Encrypted Client Hello hides it, where supported)
ALPN	Client and server agree on HTTP/2 or HTTP/1.1 inside the handshake, at no extra round trip
Certificate chain	Leaf certificate → intermediate(s) → a root the client already trusts; servers must send the intermediates
Revocation	CRLs and OCSP; Let's Encrypt shut down its OCSP service on 6 August 2025 and publishes CRLs instead, and short certificate lifetimes limit the damage of a stolen key
Resumption and 0-RTT	A returning client resumes with a pre-shared key; 0-RTT data can be replayed, so only for idempotent requests

HTTP/1.1, HTTP/2, HTTP/3 and friends

	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC over UDP
Concurrency	One request at a time per connection; browsers open about 6	Many streams multiplexed over one connection, as binary frames	Many independent streams
One lost packet	Stalls that connection	Stalls every stream (TCP head-of-line blocking)	Stalls only its own stream
Headers	Plain text, repeated	HPACK compression	QPACK compression
Changing networks	New connection	New connection	Connection IDs let it migrate from Wi-Fi to mobile

gRPC runs over HTTP/2 with Protobuf: unary calls plus client, server and bidirectional streaming. Always set a deadline; it propagates to downstream calls so abandoned work stops.
WebSocket starts as an HTTP/1.1 request with Upgrade: websocket (101 Switching Protocols), then exchanges framed messages both ways over the same TCP connection; load balancers must allow long-lived connections and idle timeouts above the ping interval.

DNS in depth

Record	Use
A / AAAA	Name → IPv4 / IPv6 address
CNAME	Alias to another name; not allowed at the zone apex (example.com), which is why providers offer ALIAS/ANAME-style records
NS, SOA	Which servers are authoritative; zone settings, including how long to cache "no such name" (negative caching)
MX, TXT	Mail servers; verification and email policies (SPF, DKIM, DMARC)
SRV, HTTPS/SVCB	Service host and port; HTTPS records advertise HTTP/3 support and other connection hints up front
CAA	Which certificate authorities may issue for the domain

TTLs trade failover speed against query load and resilience: 60 s lets you move traffic in about a minute, but some resolvers and clients cache longer than asked. DNS over HTTPS or TLS encrypts lookups; GeoDNS answers by the resolver's location (EDNS Client Subnet passes part of the user's address to improve it).

Addresses and subnets

CIDR notation 10.0.0.0/16 means the first 16 bits are the network and the rest (16 bits, 65,536 addresses) are hosts. Designing a VPC is mostly choosing non-overlapping ranges big enough for growth:

Load-balancing algorithms

Ten servers, requests arriving at random. Each server handles one request at a time and queues the rest. Pick the load and the kind of requests:

Algorithm	How	Watch out for
Round robin / weighted	Next server in turn (weights for bigger servers)	Ignores how busy each server is
Least connections / least request	Fewest in-flight requests	Many balancer instances each with a partial view can herd onto the same "idle" server
Power of two choices	Pick two at random, send to the less loaded	Nearly as good as least connections with tiny state; Envoy's least-request uses it
Latency-aware (EWMA)	Prefer servers with low recent latency	Needs decay so a recovered server gets traffic again
Consistent hashing	Same key → same server (caches, sticky sessions)	Hot keys; use bounded loads

Rate-limiting algorithms

The same traffic through five limiters, each set to 10 requests per 10 seconds:

Token bucket (AWS API Gateway, most SDKs) allows bursts up to the bucket size, then the refill rate. GCRA (redis-cell) is the same behaviour stored as a single timestamp.
Leaky bucket (NGINX limit_req) smooths traffic to a steady outflow; a burst setting decides how much may queue.
Fixed window is one counter per minute: cheap, but allows up to twice the limit across a window boundary. Sliding log is exact but stores every timestamp. Sliding-window counter weights the previous window's count, nearly exact with two counters (Cloudflare describes using this approximation).
Distributed limits: a central Redis call per request (accurate, adds latency) or local buckets synchronised in the background (fast, briefly over the limit). Adaptive concurrency limits (Netflix's library, Envoy) adjust the limit from observed latency instead of a fixed number.

Inside a Kubernetes cluster

A Service gets a virtual IP; kube-proxy programs iptables or IPVS rules on every node that translate it to a pod address. iptables rules are evaluated in sequence, so very large clusters prefer IPVS or eBPF (Cilium), which replaces kube-proxy with hash lookups in the kernel. Each translated connection also takes an entry in the kernel's connection-tracking table, which can fill up under heavy short-lived traffic.

Product by product

Product	How it works	The detail worth knowing
NGINX	A master process and event-loop workers (epoll); round robin, least connections, IP hash or consistent hash upstreams	`limit_req` is a leaky bucket with a burst setting
HAProxy	Event-driven, multi-threaded, L4 and L7; detailed health checks	Stick tables give rate limiting and affinity without an external store
Envoy	Event-loop worker threads; live configuration via xDS; outlier detection, circuit breaking, rate limiting	Data plane under Istio and many gateways; least-request uses power of two choices
AWS ALB and NLB	ALB: L7 routing by host, path, header. NLB: L4, static IPs, keeps the client's source IP	Content-based routing needs ALB
Google Cloud global load balancer	Anycast IPs served by Google Front Ends near users	One IP worldwide
Maglev, Katran	Software L4 balancers behind ECMP routers; Maglev hashing; Katran in the kernel with XDP/eBPF	Connections stay on their backend as backends change
Kubernetes Services	kube-proxy iptables or IPVS; Cilium eBPF	iptables rule count grows with services

Say it in the interview

Answers that show depth

"Why is HTTP/3 better on mobile?" A lost packet only stalls its own stream instead of every stream on the connection, setup is one round trip including TLS, and connections survive switching networks.
"Which load-balancing algorithm?" Least-request with power of two choices: close to the best possible with almost no shared state; consistent hashing only when the backend caches per key.
"Fixed window or token bucket for the API?" Token bucket per API key: it allows short bursts but caps the average, and has no boundary spike; keep the counter in Redis or approximate locally.

What is TCP head-of-line blocking in HTTP/2?

TCP delivers bytes in order, so all multiplexed streams wait for the retransmission. QUIC fixes it.

A fixed-window limiter allows 100 requests per minute. What's the most a client can send within any 60 seconds?

100 at the end of one window and 100 at the start of the next.

What is "power of two choices" load balancing?

It avoids herding and needs no global view, yet performs close to least-connections.