Networking
The Wires Everything Runs On
Every distributed system is, at bottom, machines talking to each other over a network — and the network is the one component you can never fully trust. It drops packets, adds latency, partitions, and fails in ways that don't happen inside a single machine. Understanding networking isn't optional infrastructure trivia; it's what lets you reason about why a design is slow, where a request actually goes, and how failures propagate. From the transport protocol that carries your bytes to the DNS lookup that starts every connection, to the CDN, proxy, and firewall layers that sit between client and server, this topic is the substrate under every other topic in this guide.
The reason networking earns its own section is that so many system-design decisions are really networking decisions in disguise. "Reduce latency" usually means "cache closer to the user" (CDN) or "pick the right transport" (TCP vs UDP). "Handle real-time updates" means choosing WebSockets vs SSE. "Route traffic and enforce policy" means reverse proxies and load balancers. "Secure the perimeter" means firewalls and VPNs. Getting fluent in these building blocks is what separates a design that merely names components from one that explains how a byte actually gets from a user's phone to your database and back.
When This Comes Up
- System design interviews: Networking questions hide inside nearly every problem. "How does a request reach your service?" pulls in DNS, load balancers, and reverse proxies. "How do you make this fast globally?" pulls in CDNs and Anycast. "How do users get live updates?" pulls in WebSockets vs polling vs SSE. Interviewers probe whether you understand the path a request takes and the latency/reliability implications of each hop.
- Real architecture: Choosing TCP vs UDP, tuning DNS TTLs for failover, deciding what to cache at the edge, terminating TLS at a proxy, and segmenting a network with firewalls are everyday production decisions. They directly shape latency, cost, availability, and security.
- Production incidents: "It's always DNS" is a running joke because networking issues — propagation delays, connection exhaustion, misrouted traffic, expired certs, firewall misconfigurations — are among the most common and most confusing outages. The concepts here are what let you trace a failure through the layers.
How the Sub-Topics Connect
The sub-topics follow the path of a request: the transport that carries bytes (TCP/UDP) → the application protocol on top (HTTP/HTTPS) → finding the server (DNS) → serving content close to users (CDN) → the boundary that routes and protects (load balancer/reverse proxy) → securing the perimeter (firewalls/VPN) → and finally real-time bidirectional communication (WebSockets):
1. TCP/IP & UDP
The foundation: IP addresses and routes packets between machines, while TCP and UDP are the two transport choices on top. TCP is reliable, ordered, and connection-oriented — it guarantees complete, in-order delivery at the cost of handshakes and overhead. UDP is fast and connectionless — fire-and-forget with no guarantees. The rule: if a late-but-complete delivery beats a missing one, use TCP (web, APIs, databases); if a fresh-but-lossy delivery beats a late one, use UDP (video, gaming, DNS). TCP's head-of-line blocking is also why QUIC/HTTP/3 moved back onto UDP.
2. HTTP & HTTPS
The request-response language of the web: methods, headers, and status codes, wrapped in TLS for HTTPS (confidentiality, integrity, and server identity). HTTP is stateless, which is exactly what makes the web tier horizontally scalable — state is carried explicitly via cookies and tokens. Knowing method semantics (safe/idempotent), the 4xx-vs-5xx split, and caching headers (Cache-Control, ETag) turns "just use HTTP correctly" into a real scalability strategy. The evolution from HTTP/1.1 → HTTP/2 → HTTP/3 is a story of progressively eliminating head-of-line blocking.
3. DNS
The internet's phone book: translating names into IP addresses through a distributed, hierarchical, heavily-cached lookup. But DNS is also a powerful traffic-steering tool — through record types, TTLs, and routing policies (geo, latency, weighted, failover), it directs users to the nearest region and enables regional failover. TTL is one of the most consequential knobs in system design: short TTLs give fast failover at the cost of query load. Because every connection begins with a DNS lookup, it's both foundational and a frequent source of outages.
4. CDN
A globally distributed fleet of edge caches that serve content close to users, turning a long, slow path to a distant origin into a short, fast one. The core value is physics — less distance means less latency — and the key metric is cache hit ratio. Modern CDNs go far beyond caching static assets: TLS termination, DDoS absorption, WAF, edge compute, and origin shielding. A CDN is one of the highest-leverage additions to any user-facing system because it improves latency, cost, scalability, and reliability all at once.
5. Load Balancer & Reverse Proxy
The boundary in front of your application: a reverse proxy forwards client requests to backends (clients never talk to servers directly), and a load balancer is a reverse proxy specialized for distributing traffic. Putting a proxy at the edge centralizes cross-cutting concerns — TLS termination, caching, routing, compression, rate limiting, security — so backends stay simple and stateless, and hides your topology. Understanding how a load balancer, reverse proxy, and API gateway differ (increasing application-awareness) is a common interview point.
6. Firewalls & VPN
The tools that control who can reach your systems and how distant private systems connect. A firewall filters traffic by rules with a default-deny posture, and enables network segmentation so a breach in one tier can't reach the database — containing the blast radius. A VPN creates an encrypted tunnel across untrusted networks for remote access or site-to-site links. The industry is shifting from the castle-and-moat perimeter model toward Zero Trust: never trust, always verify, so being "inside" the network grants no implicit access.
7. WebSockets
A persistent, full-duplex channel for real-time communication, where either side can push messages at any time — the right tool for chat, collaboration, gaming, and live dashboards where plain request-response HTTP falls short. A WebSocket starts as an HTTP Upgrade handshake, then becomes a lightweight bidirectional pipe. The hard part is scaling: WebSockets are stateful and pin each connection to one server, so horizontal scaling requires a pub/sub backplane (Redis, Kafka) to deliver messages across servers, plus reconnection and draining strategies.
Sub-Topics
| # | Sub-Topic | What You'll Learn |
|---|---|---|
| 1 | TCP/IP & UDP | The transport layer and when to choose reliability vs speed |
| 2 | HTTP & HTTPS | The web's protocol, TLS, statelessness, and HTTP/2/3 |
| 3 | DNS | Name resolution and DNS as a global traffic-steering tool |
| 4 | CDN | Serving content from the edge for latency, cost, and resilience |
| 5 | Load Balancer & Reverse Proxy | The boundary that routes, protects, and distributes traffic |
| 6 | Firewalls & VPN | Controlling network access and securing connections |
| 7 | WebSockets | Real-time bidirectional communication and how to scale it |