Networking
Essentials

Networking 101

At its core, networking is about connecting devices and letting them communicate. Systems are nearly always built from independent devices talking over a network.

Networks use a layered architecture (the OSI model) that greatly simplifies life for application developers sitting on top. Each layer is an abstraction: when you request a webpage you don't care which voltages represent a 1 or a 0 on the wire — you just use the next layer down. It's like calling open() instead of instructing the disk how to read bytes.

Networking Layers

The full stack is fascinating, but three layers come up most in interviews. Hover a layer to lift it.

These layers work together to enable every network communication. The higher up the stack you go, the more latency and processing is required — a fact that matters directly for the load-balancer discussion later.

A Simple Web Request

Type a URL and several layers spring into action. Here's a plain HTTP-over-TCP page load, start to finish.

IP: Routing & Addressing

The network layer is dominated by IP. Nodes get IPs (usually from a DHCP server) at boot. These addresses are arbitrary — they only mean something because we advertise them.

You can build a private network with any IPs you like, but for internet traffic to find your servers you need public IPs that are routable and allocated by a RIR. Internet routing infrastructure is optimized to find public IPs.

TCP vs. UDP

The transport layer gives you guarantees instead of a jumbled pile of packets. The three protocols are TCP, UDP, and QUIC — but the real interview choice is TCP vs. UDP. Treat QUIC as "a better TCP" without the broad adoption baseline.

When to Choose Each

Interviewers assume TCP by default — it often doesn't even need mentioning. You earn points by making the case for UDP and getting the details right. Reach for UDP when:

• Low latency is critical (real-time apps, gaming)
• Some data loss is acceptable (media streaming)
• High-volume telemetry / logs where occasional loss is fine
• You don't need browser support (or have an alternative client)

TCP vs. UDP — Quick Reference

HTTP / HTTPS

HTTP is the de-facto standard for web data: a request-response protocol. It's stateless — each request is independent, the server holds nothing about prior requests. That's good: minimize stateful surface area. Most simple HTTP servers are just a function of the request params.

Headers are flexible key/value pairs — a great lesson in interface design for unknown future use-cases. Content negotiation is the classic case: a client sends Accept-Encoding: gzip, br, the server replies with Content-Encoding: br if available — backward compatibility plus graceful degradation.

REST · GraphQL · gRPC

REST — Simple & Flexible

The most common paradigm in interviews. The core idea: clients perform operations against resources (think database tables or files). REST leans on HTTP verbs plus conventions for paths and bodies, usually with JSON. Your Core Entities often map directly to resources.

# Read a user
GET /users/{id} -> User

# Update an existing user
PUT /users/{id} -> User
{ "username": "john.doe", "email": "john.doe@example.com" }

# Create (server assigns the id)
POST /users -> User
{ "username": "stefan.mai", "email": "stefan@hellointerview.com" }

# Nested resources for relationships
GET /users/{id}/posts -> [Post]

GraphQL — Flexible Data Fetching

Open-sourced by Facebook (~2015). It lets the frontend request exactly the data it needs, solving two problems with REST:

query GetUsersWithProfilesAndGroups($limit: Int = 10, $offset: Int = 0) {
  users(limit: $limit, offset: $offset) {
    id
    username
    profile { id fullName avatar }
    groups { id name description category { id name icon } }
    status { isActive lastActiveAt }
  }
  _metadata { totalCount hasNextPage }
}

The query names the fields and nested objects; the backend responds in exactly that shape. Sweet spot: complex clients and multiple teams making wide queries over overlapping data — where the frontend needs to iterate fast.

gRPC — Efficient Service Communication

A high-performance RPC framework from Google using HTTP/2 and Protocol Buffers — like JSON but with a rigid schema for better performance and serialization.

message User {
  string id = 1;
  string name = 2;
}

service UserService {
  rpc GetUser (GetUserRequest) returns (GetUserResponse);
}

A chunky JSON object (~40 bytes) becomes a skinny binary encoding (~15 bytes) — less space, less CPU to parse:

{ "id": "123", "name": "John Doe" }   // ~40 bytes JSON
0A 03 31 32 33 12 08 6A 6F 68 6E ... // ~15 bytes protobuf

Definitions compile into client + server stubs across many languages. gRPC ships streaming, deadlines, client-side load balancing, and more — built for microservices at scale. Some benchmarks show ~10× throughput over JSON-over-HTTP.

SSE · WebSockets · WebRTC

Server-Sent Events (SSE) — Push over HTTP

A spec on top of HTTP that lets a server stream many messages over a single HTTP response. Normal HTTP gives one cohesive JSON blob you process once fully received — useless for push. SSE sends chunks:

data: {"id": 1, "timestamp": "2025-01-01T00:00:00Z", "description": "Event 1"}
data: {"id": 2, "timestamp": "2025-01-01T00:00:01Z", "description": "Event 2"}
data: {"id": 100, ...}

Each line is a separate message the client processes as it arrives (one TCP connection, many small packets).

Where to use: notifications/events as soon as they happen — e.g. keeping bidders updated on an auction's current price.

WebSockets — Bidirectional & Persistent

A persistent, TCP-style connection enabling real-time, bidirectional communication with broad support (browsers included). Both sides push without waiting for a request. Initiated via an HTTP "upgrade" so you can reuse existing session info (cookies, headers).

1. Client initiates a WebSocket handshake over HTTP (backed by a TCP connection)
2. Connection upgrades to the WebSocket protocol, taking over the TCP connection
3. Both client and server send binary messages over the connection
4. The connection stays open until explicitly closed

WebSockets don't dictate an application protocol — you have a binary channel and define your own messages (serialized JSON is a great option).

WebRTC — Peer-to-Peer

The most unusual protocol — direct peer-to-peer communication between browsers, no intermediary server for the data exchange. The only app-level protocol here that uses UDP. Great for video/audio calling and conferencing.

P2P is harder than client-server because most clients block inbound connections and sit behind a NAT. WebRTC works around this:

1. Clients connect to a central signaling server to learn about peers
2. Clients hit a STUN server to get their public IP and port
3. Clients exchange that info via the signaling server
4. Clients establish a direct P2P connection and start sending data (TURN relay as fallback)

Load Balancing

To scale you go vertical (bigger servers) or horizontal (more servers). Modern hardware is powerful, so vertical scaling goes further than people think — but in interviews, horizontal scaling is the common pattern. Adding boxes only helps if clients know which server to talk to. Enter load balancing.

Client-Side Load Balancing

The client picks the server, usually after pulling a list from a service registry/directory and periodically syncing. Fast and efficient — no extra network hop per request, only periodic sync.

Dedicated Load Balancers

When clients shouldn't know about multiple backends, or you have many uncontrolled clients needing fast updates, use a dedicated LB sitting between client and servers. It adds a hop but gives fast server-list updates and fine-grained routing control.

Health Checks & Fault Tolerance

LBs also monitor backend health and stop routing to a crashed server until it recovers — automatic failover, the basis of high availability. A TCP health check simply confirms the server accepts connections; an L7 health check makes an HTTP request and verifies a success code (200 vs. 500 or no response).

Load Balancing Algorithms

Round robin / random suit stateless apps and naturally absorb new servers. For persistent connections (SSE, WebSockets), prefer Least Connections so one server doesn't slowly hoard every active connection.

Regionalization & Latency

Global services distribute servers worldwide. A common pattern: multiple data centers per region (Amazon's "availability zones") so one building's failure doesn't take you down, replicated across cities.

The fix is data locality: keep the data needed to satisfy a query close together and close to the user. Some latency is unavoidable when users are simply far apart, but two strategies help.

Handling Failures

Servers crash, bits flip from solar flares, power is cut — and networks fail too: cables get cut, routers die, packets drop. Robust design plans for all of it.

Timeouts & Retries with Backoff

The most basic hygiene: set a timeout, and retry if a request takes too long. Retries handle transient failures well — a temporarily slow server often succeeds on retry. Idempotent APIs are key so retries don't cause harm.

But retries are double-edged: hammering a failing system makes things worse. Add backoff — wait longer between each attempt — to give the system room to recover. Add jitter (randomness) so clients don't synchronize into a jackhammer of simultaneous retries.

Idempotency

Retries with side effects are dangerous — retrying a $10 charge could bill the user $20 or $2,000. Idempotent APIs produce the same result no matter how many times they're called. Reads (GET) are naturally idempotent; for writes, use an idempotency key — a unique request identifier.

For a payment where a user buys one item per day, set the key to userID + date. The server checks whether it has already processed (or is processing) that key and runs it once. Friendly APIs wait and return the result to all callers; less-friendly ones error that the request already exists — either way, no double charge.

Circuit Breakers

The defense against cascading failures. If a database goes cold and must boot one instance at a time, a firehose of retries (a "thundering herd") can pin every instance and prevent recovery. A circuit breaker protects against this:

1. Monitor failures when calling an external service
2. When failures exceed a threshold, the circuit trips open
3. While open, requests fail immediately without making the call
4. After a timeout, the circuit goes half-open
5. A test request decides whether to close the circuit or keep it open

Apply at: external/third-party API calls, database connections & queries, service-to-service calls in microservices, resource-intensive operations, and any network call that could fail or slow down. A great answer when an interviewer deep-dives on reliability, failure modes, or disaster recovery.

Wrapping Up

Networking is the foundation connecting every component in a distributed system. The field is vast, but these four areas cover most interviews:

Test Yourself