Networking Essentials

TCP vs UDP, HTTP, WebSockets, load balancers and what actually matters in an interview.

You don't need to be a network engineer to pass a system design interview, but you do need to make good decisions about how clients and services talk to each other. This page covers the parts of networking that actually come up.

The layers that matter

Of the OSI model's seven layers, three show up in interviews:

TCP vs UDP

TCP gives you a reliable, ordered byte stream. It handles retransmission, ordering and congestion control. The cost is a connection handshake and head-of-line blocking — one lost packet stalls everything behind it.

UDP sends independent datagrams with no delivery or ordering guarantees. It's faster and lighter, and the application deals with loss.

[!INTERVIEW] Default to TCP Use TCP (via HTTP) unless you have a specific reason not to. Reach for UDP for real-time media — video calls, live game state — where a late packet is worse than a lost one.

HTTP and REST

HTTP is the default application protocol. It's stateless: each request carries everything the server needs, which makes horizontal scaling easy — any server can handle any request.

Key details worth knowing:

Methods have semantics: GET is safe and idempotent, PUT and DELETE are idempotent, POST is neither.
Status codes communicate outcomes: 2xx success, 4xx client error (400, 401, 403, 404, 409, 429), 5xx server error.
HTTP/2 multiplexes many requests over one connection; HTTP/3 runs over QUIC (UDP) to avoid TCP head-of-line blocking.

Real-time protocols

When the server needs to push data to the client, plain request/response isn't enough:

See Real-time Updates for how to fan updates out across a fleet of servers.

gRPC for service-to-service

gRPC uses HTTP/2 and Protocol Buffers: binary, strongly typed, fast, with streaming support. It's a great default for internal service-to-service calls. Keep REST for public APIs, where browser support and human readability matter. See gRPC & Protobuf for load balancing, deadlines and schema evolution.

Load balancing

Once you have more than one server, you need to spread traffic across them.

L4 load balancers route by IP and port. They're very fast and keep TCP connections intact, which makes them a good fit for WebSockets.
L7 load balancers understand HTTP. They can route by path or header, terminate TLS, and do smarter balancing — at a bit more cost.

Common algorithms: round robin, least connections (good for long-lived connections), and consistent hashing (when requests for the same key should hit the same server — see Consistent Hashing).

Client -> DNS -> CDN -> [L7 Load Balancer] -> [App Servers] -> (Database)

Timeouts, retries and backoff

Networks fail. Every remote call needs:

A timeout, so a slow dependency doesn't exhaust your threads
Retries with exponential backoff and jitter, so a recovering service isn't hammered by synchronized retries
Idempotency, so a retried request doesn't double-charge a customer
A circuit breaker, so you stop calling a dependency that's clearly down and fail fast

[!TIP] Mention these unprompted Saying "the payment call gets a 2-second timeout, retries with backoff, and an idempotency key" in one breath is a cheap, strong senior signal.

Regionalization and latency

Light in fiber covers roughly 200km per millisecond, so a round trip between continents costs ~100–150ms no matter what you do. To serve a global user base:

Put static content in a CDN close to users
Deploy to multiple regions and route users to the nearest one
Partition data by region where possible so most requests stay local