Networking Essentials

You don't need to recite the OSI model in a system design interview. But you do need to understand how data moves between machines, because every system you design is fundamentally about networked communication. When you say "the client calls the API," what happens under the hood?

This lesson covers the networking concepts that show up in interviews: the protocols you'll reference, the infrastructure that makes requests fast and reliable, and the trade-offs you'll make when choosing how services communicate.

The Life of a Request

When a user types a URL into their browser, a surprisingly long chain of events fires before they see a page. Understanding this chain helps you reason about where latency comes from and where things can fail.

In a system design interview, you'll mostly focus on steps 4-6. But knowing the full chain helps you reason about latency budgets: if DNS + TCP + TLS takes 100ms, and your user expects a 200ms response, you only have 100ms for everything else.

Protocols That Matter

What matters is knowing when to use each protocol and what trade-offs it brings. Here are the ones that come up in interviews.

TCP vs UDP

In interviews, almost everything you design will run over TCP (via HTTP). UDP comes up mainly when designing real-time systems like video streaming or live gaming where dropping a frame is better than waiting for a retransmit.

HTTP/1.1, HTTP/2, HTTP/3

HTTP/1.1 is the baseline. Without pipelining it sends one request per TCP connection at a time, so browsers work around it by opening 6+ parallel connections per domain. HTTP/2 multiplexes many requests over a single TCP connection and introduces server push and header compression. HTTP/3 replaces TCP with QUIC (built on UDP) for lower latency, especially on unreliable networks.

In an interview, you don't need to specify the HTTP version. But knowing that HTTP/2 enables efficient multiplexing is useful when discussing how a CDN or API gateway handles thousands of concurrent connections.

WebSockets

HTTP is request-response: the client asks, the server answers. WebSockets upgrade an HTTP connection into a persistent, bidirectional channel where either side can send data at any time. This is the go-to protocol for real-time features: chat messages, live notifications, collaborative editing, stock tickers.

DNS

DNS (Domain Name System) translates human-readable domain names into IP addresses. It's a distributed, hierarchical system, one of the oldest and most battle-tested distributed databases on the internet.

In system design interviews, DNS matters for two reasons. First, DNS-based load balancing: you can return different IP addresses for the same domain to distribute traffic across data centers or regions. Second, TTL (time-to-live): DNS records are cached, and the TTL determines how quickly changes propagate. A short TTL (60s) lets you failover quickly but increases DNS query load. A long TTL (3600s) reduces load but makes failovers slow.

CDNs

A Content Delivery Network is a global network of servers that cache and serve content from locations physically close to users. Instead of every request traveling to your origin server in Virginia, a user in Tokyo gets served from a CDN edge node in Tokyo.

CDNs are essential for two things: static assets (images, CSS, JS) where the content rarely changes, and reducing latency for geographically distributed users. A well-configured CDN can cut response times from 200ms to 20ms for cached content.

Push vs Pull CDN: a push CDN requires you to upload content explicitly, so you control what's cached. A pull CDN fetches content from your origin on the first request and caches it. That's simpler to set up, though the first request is slow. Most modern CDNs (CloudFront, Cloudflare) use pull-based caching with configurable TTLs.

Load Balancers

A load balancer distributes incoming requests across multiple servers. It sits between the client and your application servers, deciding which server handles each request. Every non-trivial system design will include at least one.

Load Balancing Strategies

L4 vs L7 Load Balancing

Layer 4 (transport) load balancers route based on IP address and TCP port. They don't inspect the request content. They're fast and efficient but can't make routing decisions based on URL path or headers. Layer 7 (application) load balancers inspect HTTP requests and can route based on URL, headers, cookies, or request body. They're more flexible but add more processing overhead.

In interviews, you'll almost always mean L7 when you say "load balancer." Mention L4 when performance is critical and you don't need content-based routing, for example in front of a database proxy layer.

Proxies

A proxy is a server that sits between a client and a destination server, forwarding requests on behalf of one side. There are two types, and the distinction matters.

In system design interviews, you'll almost exclusively work with reverse proxies. Your load balancer is one, your API gateway is one, and your CDN edge nodes are too. They're all the same pattern applied at different layers.

Using This in Interviews

You'll rarely be asked to explain networking concepts directly. Instead, they inform your design decisions. Here's how to weave them in naturally:

Don't spend interview time explaining what a load balancer does. The interviewer knows. Mention it, draw it, and move on to the interesting parts. The value is in knowing *when* to include these components. Defining them earns you nothing.