Networking Essentials
Why This Matters
Every system design answer involves network communication. Understanding protocols, latency, and how data moves between services is foundational.
OSI Model (Simplified for Interviews)
| Layer | Name | Key Protocols | Interview Relevance |
|---|
| 7 | Application | HTTP, gRPC, WebSocket, DNS | API design, routing |
| 4 | Transport | TCP, UDP | Reliability vs speed |
| 3 | Network | IP, BGP | Routing, anycast |
| 2 | Data Link | Ethernet | Rarely discussed |
| 1 | Physical | Fiber, copper | Rarely discussed |
Focus on layers 4 and 7 — that's where 95% of interview questions live.
TCP vs UDP
TCP (Transmission Control Protocol)
- Connection-oriented — 3-way handshake (SYN, SYN-ACK, ACK)
- Reliable — guarantees delivery, ordering, no duplicates
- Flow control — receiver advertises window size
- Congestion control — slow start, congestion avoidance
- Use cases: HTTP, database connections, file transfers, APIs
UDP (User Datagram Protocol)
- Connectionless — no handshake
- Unreliable — no delivery guarantee, no ordering
- Lightweight — minimal overhead (8 byte header vs 20+ for TCP)
- Use cases: Video streaming, gaming, DNS lookups, VoIP
When to Choose What
Need reliability + ordering? → TCP
Need speed + low latency + can tolerate loss? → UDP
Need reliability + speed? → TCP with optimizations, or UDP + application-level reliability (QUIC)
HTTP Protocol
HTTP/1.1
- One request per TCP connection (or keep-alive for reuse)
- Head-of-line blocking — requests queue behind each other
- Text-based headers (verbose)
HTTP/2
- Multiplexing — multiple streams on single TCP connection
- Header compression (HPACK)
- Server push — server can send resources proactively
- Binary protocol — more efficient parsing
- Still has TCP head-of-line blocking at transport layer
HTTP/3 (QUIC)
- Built on UDP instead of TCP
- No head-of-line blocking — streams are independent
- 0-RTT connection — faster handshake
- Built-in encryption (TLS 1.3)
- Used by Google, Cloudflare, Meta
HTTP Methods for API Design
| Method | Idempotent | Safe | Use |
|---|
| GET | Yes | Yes | Read resources |
| POST | No | No | Create resources |
| PUT | Yes | No | Full update |
| PATCH | No* | No | Partial update |
| DELETE | Yes | No | Remove resources |
HTTP Status Codes (Must Know)
| Range | Meaning | Key Codes |
|---|
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirect | 301 Permanent, 302 Found, 304 Not Modified |
| 4xx | Client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | Server error | 500 Internal, 502 Bad Gateway, 503 Unavailable, 504 Timeout |
DNS (Domain Name System)
How DNS Works
User types google.com
→ Browser cache
→ OS cache
→ Router cache
→ ISP's recursive resolver
→ Root nameserver (.)
→ TLD nameserver (.com)
→ Authoritative nameserver (google.com)
→ Returns IP: 142.250.80.46
DNS Record Types
| Type | Purpose | Example |
|---|
| A | Domain → IPv4 | google.com → 142.250.80.46 |
| AAAA | Domain → IPv6 | google.com → 2607:f8b0:4004:800::200e |
| CNAME | Alias → another domain | www.google.com → google.com |
| MX | Mail server | google.com → smtp.google.com |
| NS | Nameserver | google.com → ns1.google.com |
| TXT | Arbitrary text | SPF, DKIM, verification |
| SRV | Service discovery | _http._tcp.example.com |
DNS in System Design
- TTL (Time to Live) — how long to cache DNS records
- DNS-based load balancing — return different IPs (round-robin)
- GeoDNS — return IP based on client location (global LB)
- DNS failover — update records to point to healthy servers
- Low TTL for services that need fast failover (30-60s)
- High TTL for stable services (3600s+)
CDN (Content Delivery Network)
How CDNs Work
Client request → Nearest CDN Edge (PoP)
→ Cache HIT → Return cached content (fast!)
→ Cache MISS → Fetch from origin → Cache → Return
Pull vs Push CDN
| Pull CDN | Push CDN |
|---|
| How | CDN fetches from origin on first request | You upload content to CDN |
| When to use | Dynamic content, large catalogs | Static assets you control |
| Pros | Simple, automatic | Full control, predictable |
| Cons | First request is slow (cache miss) | More operational overhead |
CDN Use Cases in Interviews
- Static assets — images, CSS, JS, videos
- API responses — cache GET responses at edge
- Video streaming — Netflix/YouTube use CDN heavily
- Security — DDoS protection, WAF at edge
Key CDN Providers
- CloudFront (AWS), Cloud CDN (GCP), Azure CDN, Cloudflare, Akamai, Fastly
WebSockets
What
- Full-duplex, persistent connection between client and server
- Starts as HTTP upgrade, then switches to WS protocol
- Both sides can send messages at any time
When to Use
- Chat applications — real-time messaging
- Live notifications — push updates
- Collaborative editing — Google Docs
- Gaming — real-time game state
- Live dashboards — stock tickers, monitoring
When NOT to Use
- Simple request-response APIs (use HTTP)
- Infrequent updates (use polling or SSE)
- High fan-out broadcast (consider SSE or pub/sub)
WebSocket vs Alternatives
| Tech | Direction | Connection | Best For |
|---|
| HTTP Polling | Client → Server | New connection each time | Simple, infrequent updates |
| Long Polling | Client → Server | Held open until data | Near real-time, simple |
| SSE | Server → Client | Persistent, one-way | Live feeds, notifications |
| WebSocket | Bidirectional | Persistent, full-duplex | Chat, gaming, collab |
Proxies
Forward Proxy
- Sits between client and internet
- Client knows it's using a proxy
- Use cases: privacy, access control, caching
Reverse Proxy
- Sits between internet and servers
- Client doesn't know it exists
- Use cases: load balancing, SSL termination, caching, compression, security
- Examples: Nginx, HAProxy, Envoy, Traefik
Key Networking Numbers
| Metric | Value |
|---|
| Bandwidth within datacenter | 1-100 Gbps |
| Bandwidth across regions | 1-10 Gbps |
| RTT within datacenter | 0.5 ms |
| RTT same region | 1-5 ms |
| RTT cross-continent | 50-150 ms |
| Typical HTTP request (no content) | 50-200 ms |
| DNS lookup (uncached) | 20-120 ms |
| TLS handshake | 50-150 ms |
Resources
Previous: 01 - Fundamentals of System Design | Next: 03 - APIs & Communication Patterns