What actually changes your whiteboard
You won't be asked to draw the OSI model. You'll be asked why you picked WebSockets over SSE, why your load balancer terminates TLS, and what happens when a payment call times out. This page is the slice of networking that changes those answers — nothing you won't use.
IP · TCP/UDP · HTTP/WS
REST default · GraphQL/gRPC when earned
SSE push · WebSockets bi-di · WebRTC media
LB · CDN · retries · circuit breakers
Default to TCP + HTTPS/REST + L7 load balancing. Justify UDP, WebSockets, gRPC, or WebRTC only when the problem forces your hand — not because they sound advanced.
Three layers, compressed
Layers are an abstraction, nothing more: you call the layer below and never think about what's under it — the same reason you call open() instead of steering a disk head yourself. For interviews, three layers matter. Everything below L3 is a vendor's problem.
- L3 — network. IP handles addressing and routing: best-effort delivery to a destination address. You bring it up when placing regions or discussing NAT; otherwise it's assumed.
- L4 — transport. TCP, UDP, and QUIC add end-to-end guarantees — or deliberately skip them. This is where your first real choice lives.
- L7 — application. HTTP, WebSockets, WebRTC, DNS. This is where you'll spend most of the interview.
You design at L7, you choose L4 guarantees, and you mostly assume L3 works — until you're placing regions or debugging why two peers can't reach each other.
What a single request actually costs
Type a URL and six things happen before you see a pixel. Each one has a cost, and that cost is the entire argument for persistent connections and multiplexing.
- DNS resolution — domain → IP
- TCP handshake — SYN → SYN-ACK → ACK
- HTTP request — e.g. GET for the page
- Server processing — the latency most SWEs think about
- HTTP response — status, headers, body
- TCP teardown — FIN/ACK/FIN/ACK four-way close
Connection setup isn't free. That single fact justifies keep-alive, HTTP/2, and every persistent-connection design you'll propose later.
IP addressing — the one thing to say about L3
Nodes get an IP from DHCP at boot. A private IP is yours to invent; a public IP has to be allocated and announced so the internet's routers actually know where to send packets addressed to it. That's the whole L3 story most interviews need — deep internet routing is a fascinating rabbit hole and firmly out of scope here.
Bring up public vs. private IP and NAT exactly twice: peer-to-peer (WebRTC) and multi-region routing. Otherwise leave L3 alone.
TCP vs UDP — your first real choice
Three protocols live at L4: TCP, UDP, QUIC. Interviews almost always collapse to TCP vs UDP. Treat QUIC as "TCP, modernized" — HTTP/3 rides on it, but only bring it up if the interviewer signals they care about the wire format.
UDP has almost nothing on top of IP: no delivery guarantee, no ordering, no dedup, an 8-byte header. Choose it when latency has a hard number attached — sub-100ms voice, live video, gaming, telemetry — and losing a packet is cheaper than waiting for it. VoIP drops a glitch rather than stall the whole call retransmitting a syllable that's already stale by the time it arrives.
TCP is the workhorse: three-way handshake, then a stateful, ordered, error-checked stream with flow and congestion control, at a 20–60 byte header cost. Default here. Reject UDP the moment correctness matters more than the last 50ms of latency — which is most of the time.
Assume TCP. Move to UDP only when you can name the latency number that makes retransmission the wrong trade — then say what the browser story is, because plain UDP doesn't exist in a browser tab.
HTTP/HTTPS — stateless by design
HTTP is stateless: each request stands alone, which is a gift, not a limitation — it's the reason a simple HTTP server can be a pure function of the request. Minimize stateful surface area wherever you can get away with it.
Methods: GET/POST/PUT/PATCH/DELETE. Status codes: 2xx/3xx/4xx/5xx. Headers are flexible key/value metadata — and your extensibility valve: Accept-Encoding lets a client advertise gzip/brotli support without either side needing to agree on a version number. Steal that pattern before you spin up a new endpoint just to add an option.
- GET — fetch; idempotent; typically no body
- POST — create / submit
- PUT — replace a resource
- PATCH — partial update
- DELETE — remove; should be idempotent
- 200 OK · 201 Created
- 301 permanent redirect · 302 temporary
- 401 Unauthorized · 403 Forbidden · 404 Not Found · 429 Too Many Requests
- 500 Server Error · 502 Bad Gateway
HTTPS stops the mailbag from being read in transit. It says nothing about who's holding the pen: don't trust a user ID that arrives in the request body without validating it server-side against the authenticated session. An attacker who can edit bodies will happily edit IDs and read data that isn't theirs.
HTTPS everywhere, no exceptions. Validate identity server-side, never from the payload. Treat headers as where new behavior goes, not new endpoints.
REST outside, gRPC inside
REST models resources with HTTP verbs and conventional paths — GET /users/{id}, PUT /users/{id}, nested GET /users/{id}/posts. Your core entities usually map straight across. Default to REST in interviews; reach for anything else only when REST demonstrably can't meet the requirement in front of you.
GraphQL fixes under- and over-fetching by letting the client name the exact fields it wants. It earns its place when clients genuinely differ — mobile vs. web, third-party integrators — and costs you resolver complexity and cacheability in return. In an interview with one fixed set of screens, GraphQL is usually in the way, not the answer.
gRPC trades JSON for Protocol Buffers over HTTP/2 — a payload that's bytes where JSON is a paragraph — plus generated stubs across languages and native streaming. It shines between services you control on both ends. Don't ship it as a public browser API: tooling and adoption still lag REST there by years.
REST for anything public. gRPC for the hot path between your own services. GraphQL only when client-shape flexibility is the actual stated problem — not a default.
SSE, WebSockets, WebRTC — pick by direction
SSE streams events over one long-lived HTTP response. It's the right call for one-directional push — auction prices, live scores — and it comes with footguns interviewers rarely probe but production teaches fast: middleboxes buffer chunks, and a reconnecting client needs the server to replay from the last event ID or it silently loses updates.
WebSockets upgrade the connection so both sides can push anytime — and every hop in between (firewall, proxy, load balancer) has to support that upgrade. Use it when both sides genuinely talk: chat, collaborative editing, games. Don't reach for it for one-way updates; a stateful connection per client is expensive to hold open at scale, and defaulting to WebSockets without justification reads as a candidate who hasn't run one in production.
WebRTC is peer-to-peer media over UDP: a signaling server introduces the peers, STUN helps them punch through NAT, TURN relays the bytes when a direct path isn't possible. It exists for one job — audio/video calling. Collaborative editors still want a central server for document state and conflict resolution; don't go peer-to-peer just because "realtime" is in the prompt. WebRTC is lossy and painful even done right — stay on it only for A/V, and route everything else through a server you control.
One-way push is SSE. Two-way chatter is WebSockets. Peer-to-peer is WebRTC, and only for audio/video — don't design it for anything else.
Load balancing — client-side, dedicated, L4 vs L7
Scale vertically while hardware allows it; interviews usually want horizontal scale, which is useless the moment clients can't tell which box to hit. That routing problem is load balancing.
Client-side load balancing skips the extra hop: the client picks a backend from a registry it polls or gets pushed. It works when clients are few and controlled (gRPC between your own services) or many but slow-changing (DNS round robin, with a TTL you control). Reject it the moment membership needs to change faster than your clients notice.
Dedicated load balancing adds a hop in exchange for instant membership updates and content-aware routing. Whether that hop is L4 or L7 is the actual decision.
L4 routes on IP/port and pins a connection to one backend for its lifetime — cheap, and the only sane choice once WebSockets are in the picture. L7 terminates HTTP and can route on path, header, or cookie — more CPU, but it's how you split /api from /web on the same domain. Default to L7 for HTTP; drop to L4 the moment a connection needs to stick.
Health checks pull dead nodes out of rotation. Round robin and random suit stateless traffic; least-connections is the right call for long-lived SSE/WebSocket connections, where request count says nothing about actual load.
HTTP defaults to L7. The instant WebSockets enter the design, you're justifying L4 — say so before the interviewer asks.
Regions, latency, and CDNs
Light in fiber moves at roughly 200,000 km/s. NYC to London is already ~56ms round-trip before a server does any work — physics sets your floor, not your code. Keep data near the compute, and compute near the user.
A CDN caches at edge points of presence — the right tool for anything static or cacheable: images, JS, sometimes even search results. It cuts both latency and origin load.
Regional partitioning is different: shard by geography and co-locate app + database per region, so a Miami rider's request never needs a driver row sitting in NYC. Group nearby cities into a region with its own data center rather than routing every read across an ocean.
Cache what's shared globally at the edge. Partition what's sticky to a user or geography at the region. Conflating the two is the usual mistake.
Timeouts, retries, idempotency, circuit breakers
The network fails. Cables get cut, routers die, packets vanish. Design for the request that never comes back, not just the one that does.
Timeouts, plus retries with exponential backoff and jitter — skip the jitter and every client backs off on the same schedule, then slams the server together on the next attempt. Retries are only safe if the operation is idempotent, which is the next problem.
Idempotency keys solve the double-charge problem: key the logical operation (a client-generated UUID, or user + action + date) and let the server dedupe against it. A well-behaved API returns the original result on a repeat; a strict one returns 409. Either beats a second charge.
Circuit breakers stop one dead dependency from taking down everything that calls it: watch the error rate, trip open and fail fast, wait out a cooldown, half-open to test the water, close on success. Put one in front of every third-party call, every cross-service call, anything that can hang instead of failing on its own.
When reliability comes up, say the four words in order: timeouts, backoff-with-jitter, idempotency, circuit breakers. Skipping jitter or idempotency is the usual tell that someone's reciting this rather than having shipped it.
Interview networking scenarios
LB quick guide
| Layer | Operates on | Example |
|---|---|---|
| L4 | IP:port | TCP passthrough, NLB |
| L7 | HTTP path/host | ALB, Nginx, Envoy |
Failure modes to mention
Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).
Cost and performance levers
Interview Q&A by level
Practice saying these out loud for networking. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.
Wrapping up
Networking connects every distributed component. For interviews, lock these:
- Basics — IP, DNS, TCP/IP mental model
- Protocols — TCP vs UDP, HTTP/S, WebSockets, gRPC, SSE, WebRTC (narrowly)
- Load balancing — client-side vs dedicated; L4 vs L7
- Reality — regions, CDNs, retries, idempotency, circuit breakers
Networking choices hit latency, throughput, reliability, and security. Justify defaults against the prompt — there's rarely one right answer; interviewers grade your trade-off talk.
For push delivery (polling → SSE → WebSockets → WebRTC) and server fan-out (pub/sub vs consistent hash), see the full pattern deep dive: Real-time updates.