Networking
DNS, TCP/UDP, HTTP, WebSockets, CDN
The problem
Every system starts with a client talking to a server. Understanding what that conversation actually costs — lookups, handshakes, round trips — is what lets you reason about latency and why chat apps, video calls, and regular websites are built differently.
DNS — the internet’s phone book
You type a domain, DNS translates it to an IP address. The answer is cached everywhere — browser, OS, ISP — which makes lookups fast and explains why DNS changes take time to propagate: millions of cached copies of the old answer have to expire first. "Fast, but might be stale" is maybe the single most recurring trade-off in system design, and this is its first appearance.
TCP vs UDP — phone call vs postcard
TCP is a phone call: a connection is established first (the three-way handshake), data arrives complete and in order, and lost packets are re-sent. The cost is round trips. UDP is a postcard: no handshake, no ordering, no retransmission — fast, but lossy. Rule of thumb: TCP for almost everything (websites, APIs, databases); UDP when fresh-but-lossy beats complete-but-late (video calls, gaming — a two-second-old frame is worse than no frame).
HTTP and its big quirk
HTTP is the request/response language spoken over TCP: client asks, server answers. Its defining quirk is that it’s stateless — every request is a stranger, the server keeps no memory of the last one. Cookies and sessions exist to fake continuity on top of a forgetful protocol.
When the server needs to speak first
HTTP’s rhythm is strictly client-initiated, but chat messages and live updates originate on the server. The escalation ladder: polling (client asks "anything for me?" every few seconds — wasteful, laggy), long polling (server holds the question open until there’s an answer), and WebSockets (a persistent two-way connection; the server just sends). WebSockets cost server memory — every open connection is held state, and a crashed server triggers a reconnect storm unless clients back off with randomized delays. Server-Sent Events (SSE) is the simpler one-way cousin for live feeds.
CDN — you can’t speed up light
A user in Tokyo requesting a photo from a server in Virginia pays ~150–200ms of physics, every time. The only move left is putting copies closer: edge servers worldwide cache static content. Most CDNs are lazy (pull-through): the first requester in a region pays the slow origin trip and the edge keeps a copy for everyone after. Popularity isn’t decided in advance — it emerges.
When things break
DNS outage → nobody can even find you (mitigate: multiple DNS providers, low TTLs). CDN miss with origin down → a well-configured edge can serve its stale copy, making some outages invisible. WebSocket drops → reconnect with randomized backoff. And TCP’s in-order guarantee means one lost packet stalls everything behind it — head-of-line blocking — which HTTP/3 (QUIC) fixes by rebuilding reliability on top of UDP.