Networking fundamentals

TCP is the workhorse: it establishes a connection via a three-way handshake (SYN, SYN-ACK, ACK), guarantees that data arrives in order, retransmits lost packets, and provides flow and congestion control. The cost is overhead — each connection has setup latency and per-packet acknowledgements.

UDP is connectionless: you send a datagram and hope it arrives. No setup, no acknowledgement, no ordering guarantee. It's faster because there's no overhead, but the application must handle loss and reordering.

When to use UDP in a system design interview: real-time media (VoIP, video streaming, gaming) where a dropped frame is better than a delayed one, high-volume telemetry where occasional loss is acceptable, and DNS lookups (simple query-response, retried at the application level).

For everything else — web APIs, databases, file transfer, messaging — TCP is the default. Most interviewers will assume TCP unless you explicitly propose UDP and justify it.

Modern compromise: QUIC (the protocol under HTTP/3) runs on UDP but adds reliability, encryption, and multiplexing. Each stream has independent loss recovery, so a dropped packet in one stream doesn't block others — solving TCP's head-of-line blocking problem. QUIC is particularly good on mobile (survives network switches without reconnection).

REST uses HTTP + JSON. It's well-understood, works everywhere (including browsers), and interviewers expect it as the default. Resource-oriented (GET /users/123, POST /orders), uses standard HTTP verbs and status codes. Easy to debug with curl.

gRPC uses HTTP/2 + Protocol Buffers (binary serialization). Protobuf payloads are usually smaller and cheaper to encode and parse than JSON, and HTTP/2 multiplexes many calls over one connection, so gRPC often uses less bandwidth and CPU on busy internal paths. How much depends on your payloads, so benchmark before quoting a multiplier. Strong typing via .proto definitions means many contract errors are caught at build time rather than runtime. gRPC natively supports streaming (client, server, and bidirectional), deadlines for timeout propagation, and client-side load balancing.

The common pattern in production: REST for external/public APIs (browser-compatible, easy to integrate), gRPC for internal service-to-service calls (fast, typed, streaming). Many companies run this dual-protocol architecture.

In interviews, default to REST. Propose gRPC when the interviewer probes on internal service performance, when you have a microservices architecture with high call volumes between services, or when you need streaming. Don't propose gRPC just to sound sophisticated — justify it with a specific performance or streaming need.

SSE (Server-Sent Events) is a one-way channel: the client opens an HTTP connection, and the server pushes messages down it as they happen. It's built on standard HTTP, works with existing load balancers and proxies, and auto-reconnects on disconnection. Think of it as a long-lived HTTP response that sends multiple messages over time.

WebSocket upgrades an HTTP connection to a persistent, bidirectional TCP channel. Both client and server can send messages at any time. It's necessary when the client needs to push data frequently (chat, collaborative editing, gaming).

The key decision: if you only need server-to-client push (notifications, live feeds, dashboards), SSE is simpler and should be your default. WebSockets add significant infrastructure complexity — you need stateful connection management, special load balancer handling, reconnection logic, and your horizontal scaling story gets harder because connections are pinned to specific servers.

In interviews, proposing WebSocket without justifying bidirectional need is a red flag. Many candidates default to WebSocket for anything "real-time" when SSE would be sufficient and simpler. Name the direction of data flow, then pick the simpler option.

GeoDNS (latency-based routing) resolves the same domain to different IPs based on where the query appears to come from. The authoritative server usually sees the recursive resolver's IP, not the user's, and sometimes an EDNS Client Subnet hint of the user's network. Users in Europe typically get the EU region IP, users in Asia get APAC — unless they use a far-away resolver or VPN. This is the first layer of global load balancing, before your request even reaches a server.

DNS failover: health-check endpoints probe your regions. When a region is unhealthy, DNS stops returning its IP. With short TTLs (60s), new lookups often move within roughly the TTL, but it isn't a hard bound: resolvers and clients can cache longer, and existing connections stay open until they fail.

Weighted routing: 95% of DNS responses point to the stable deployment, 5% to canary. Cheap traffic splitting for canary deploys without touching load balancers.

TTL tradeoffs: short TTL (60s) = fast failover but more DNS queries and more load on resolvers. Long TTL (3600s) = less DNS traffic but slow failover. Some ISP resolvers ignore TTLs entirely. Don't rely on DNS alone for fast failover — layer it with health checks at the load balancer.

Connection pooling: every new TCP connection costs a 3-way handshake plus TLS setup — 2-3 round-trips of pure latency plus TLS CPU. At 1000 QPS, that's 1000 handshakes/sec wasted. Connection pools pre-establish and reuse connections. HTTP/2 multiplexes many requests over one connection, making pools even more efficient. At scale this is table stakes.