System Design Key Concepts
Why Networking Matters
In a distributed system the network is the least reliable part, and you cannot design something scalable without understanding how data moves between nodes.
An interview expects you to reason about three things: the protocols services use to talk to each other, the transport trade-off between reliability and speed, and how traffic is routed to the right place. This guide skips the academic theory and sticks to the networking concepts that actually show up in real architecture.
1. The OSI Model: What You Actually Need
The OSI model has seven layers, but system design interviews really only care about two of them: Layer 4, the transport layer, and Layer 7, the application layer.
Layer 4 is the transport layer, the "how" of delivery. It moves packets between machines using TCP or UDP, and it knows only IP addresses and ports. An L4 load balancer routes on that information alone, which makes it very fast but blind to the message content.
Layer 7 is the application layer, the "what" of the message. It carries the actual application data over protocols like HTTP, SMTP, FTP, and WebSocket. An L7 load balancer such as Nginx or HAProxy can read the request, the URL path or a cookie, and route on it, for example sending /images to an image server.
2. TCP vs UDP: The Classic Trade-off
Every time you send data you choose between reliability and speed: TCP gives you the first, UDP the second. It is a binary choice that shapes your system's performance.
TCP (Transmission Control Protocol)
TCP is connection-oriented and guarantees that data arrives in order and without errors.
Before any data flows, TCP runs a three-way handshake (SYN, SYN-ACK, ACK) to set up the connection, which adds a round trip of latency. If a packet is lost, TCP resends it; that prevents corruption but causes head-of-line blocking, where a lost packet 1 makes packet 2 wait and stalls the stream. TCP also applies flow control, slowing the sender automatically when the receiver is overwhelmed.
It is the right choice for web browsing (HTTP/HTTPS), file transfers (FTP), email (SMTP), and database connections.
UDP (User Datagram Protocol)
UDP is connectionless. It fires off packets, called datagrams, immediately, without checking whether the receiver is ready.
There is no handshake and no acknowledgment, so you send the data and hope it arrives. That makes it extremely low latency but also unreliable, since packets can arrive out of order, be duplicated, or vanish. If the application cares, it has to handle those cases itself.
It suits real-time video streaming, online gaming, DNS lookups, and VoIP.
| Feature | TCP | UDP |
|---|---|---|
| Connection | 3-way Handshake (Stateful) | No connection (Stateless) |
| Reliability | Guaranteed delivery | Best effort (Data loss possible) |
| Ordering | Guaranteed order | No ordering guarantee |
| Speed | Slower (overhead + acks) | Faster (no overhead) |
| Use Case | Web, Email, File Transfer | Gaming, Live Video, DNS |
Comparison: TCP vs UDP
3. DNS (Domain Name System)
DNS is the phonebook of the internet. It translates human-readable domain names like google.com into the IP addresses like 142.250.190.46 that machines actually use.
Resolving a name is a journey through a chain of caches and servers. The browser checks its own cache first, then the operating system checks its local cache. On a miss, the request goes to your ISP's recursive resolver, which does the real work: it asks a root server where to find .com, the root points it to the .com TLD server, the TLD server points it to the authoritative name server (such as AWS Route 53) that holds the actual record, and the resolver returns the IP to you.
DNS Records Cheat Sheet
Know the common record types:
- A maps a domain to an IPv4 address.
- AAAA maps a domain to an IPv6 address.
- CNAME maps a domain to another domain (for example
m.example.compoints tomobile.example.com). - MX directs email to a mail server.
4. HTTP Protocols: Evolution
HTTP is the application protocol that powers the web, and it has evolved substantially to get faster.
HTTP/1.1 (The Old Standard)
HTTP/1.1 is a plain-text protocol that loads resources sequentially. It opens a new TCP connection per request, or reuses one serially, so a single slow response, a large image say, blocks every CSS and JS file queued behind it. This is head-of-line blocking at the request level.
HTTP/2 (The Current Standard)
HTTP/2 switches to a binary protocol and adds multiplexing: many requests (CSS, JS, images) travel concurrently over a single TCP connection without blocking each other. It also compresses headers with HPACK to cut the bytes on the wire.
HTTP/3 and QUIC (The Future)
HTTP/3 is built on UDP rather than TCP, through a protocol called QUIC (Quick UDP Internet Connections). TCP's handshakes and packet-loss recovery add delay; QUIC delivers TCP-like reliability with UDP-like speed and removes head-of-line blocking down at the packet level.
5. WebSockets vs Long Polling
How do you build real-time features like chat or live notifications? Plain HTTP is request-response: the client asks and the server answers, and the server cannot speak until spoken to.
Long polling is the legacy workaround. The client sends a request and the server holds it open, answering only when it has new data; the moment it replies, the client opens another request. It is easy to implement and works everywhere, but it carries high server overhead and is not truly real-time.
WebSockets are the modern answer. They open a persistent, bi-directional tunnel where either side can send at any time. That gives very low latency and high efficiency, at the cost of holding stateful connections on the server, which is harder to scale.
Interview Cheat Sheet: Protocol Selection
When you define the interfaces in a system design, a few defaults cover most cases:
- Standard APIs and CRUD are best served by REST over HTTP/HTTPS, which is cacheable, stateless, and universal.
- Microservice-to-microservice calls favor gRPC, which runs Protobuf (binary) over HTTP/2 and is far smaller and faster than JSON over HTTP/1.1.
- Real-time chat and feeds want WebSockets for low-latency, bi-directional messaging.
- Video streaming and gaming lean on UDP, or WebRTC, where speed matters more than perfect accuracy.