10 networking interview questions on load balancing, latency budgets and geography, each with the correct answer and a full explanation.
Load balancing
Chat clients hold WebSockets behind an L7 load balancer using round robin. After a rolling deploy, the first nodes to come back hold most connections while the newest nodes sit nearly idle. What actually fixes the imbalance?
Show answer
Answer
Balance on active connections (least connections) and have overloaded nodes gradually shed connections so clients reconnect with jitter
Round robin balances new connections, not existing ones, and long lived sockets never move on their own. Least connections steers new ones to idle nodes and controlled shedding redistributes the old ones. Sticky sessions make it worse by pinning clients to where they already are; it is the common wrong full fix. L4 versus L7 does not change that connections are long lived. Health check intervals affect failure detection, not distribution.
You need to route /api/* to one service and /images/* to another, and add a header with the client's request id. Which load balancer type is required?
Show answer
Answer
L7 (HTTP) load balancer
Path routing and header rewriting need the balancer to parse HTTP, which is L7. An L4 balancer forwards TCP or UDP flows by address and port and never sees the path. DNS round robin only picks an IP per lookup. Anycast routes packets to the nearest site and knows nothing about HTTP.
A legacy app stores sessions in process memory, so the team enables cookie based sticky sessions. Which problem does this introduce?
Show answer
Answer
Load skews toward nodes with heavy users, and when a node dies or is drained its users lose their sessions
Affinity trades even balancing for locality: hot users pile on one node, autoscaling helps only new users, and a node failure takes its sessions with it. The usual fix is an external session store. TLS still works, the L7 balancer terminates it to read the cookie. Cookie stickiness actually requires L7, not L4. It adds no meaningful latency.
Your LB health check hits /health, which queries the shared database. The database has a 10 second slowdown and every app node fails its check at once. What is the problem with this design?
Show answer
Answer
A deep check tied to a shared dependency can mark the whole fleet unhealthy at once, so the LB has nowhere to send traffic
Liveness checks for load balancing should reflect whether this node can serve, not whether a shared dependency is slow, otherwise a dependency blip removes every node and turns a partial outage into a total one. Many LBs fail open when all targets are unhealthy, but you should not rely on it. Transport protocol is irrelevant. A 1 ms interval only adds load. Checks must run continuously to catch node failures.
Requests to a service vary wildly in cost: most take 5 ms but some take 2 s. With plain round robin, some backends build long queues while others are idle. Which algorithm usually helps most?
Show answer
Answer
Least outstanding requests (or power of two choices on active requests)
Picking the backend with fewer in flight requests reacts to actual load, so slow requests do not stack up on one node. Random has the same blindness as round robin. IP hash pins clients to backends and ignores load. Weighted round robin with equal weights is just round robin.
Behind an L7 load balancer, your app logs every request as coming from 10.0.3.7, the LB's address. How do you get the real client IP?
Show answer
Answer
Read X-Forwarded-For (or Forwarded) set by the LB, trusting only the entry your own LB appended
An L7 proxy opens its own connection to the app, so the TCP source is the proxy. It records the client in X-Forwarded-For or Forwarded. Clients can spoof earlier entries, so trust only what your proxy added. The TCP source address is accurate, it is just the LB. A client sent IP is untrustworthy and often a private NAT address. DNS changes nothing here.
New York to Sydney is about 16,000 km. Light in fiber travels roughly 200,000 km/s. What is the best possible RTT, ignoring routing detours and processing?
Show answer
Answer
About 160 ms
One way is 16,000 / 200,000 = 80 ms, so a round trip is at least 160 ms. Real RTTs are higher because cables do not follow great circles. 80 ms is the one way figure, the most common mistake. 40 ms would need faster than light. 320 ms double counts the round trip.
An app server is in us-east. A user in Singapore (RTT 230 ms) loads a page that makes 3 sequential API calls, each needing one round trip on an already warm connection. The product team wants under 300 ms. What is the effective fix?
Show answer
Answer
Serve from a region near Singapore (or collapse the 3 calls into one and cache at the edge), because 3 x 230 ms is already 690 ms of pure RTT
Sequential round trips over a long RTT dominate; only fewer round trips or a shorter distance helps. Bandwidth does not reduce RTT for small requests. Faster serialization saves microseconds to milliseconds. Gzip shrinks bytes but small API responses already fit in a few packets.
Mobile users reconnect often and each new connection costs TCP plus TLS handshakes on a 200 ms RTT. Which change cuts the most connection setup time for returning clients?
Show answer
Answer
Use TLS 1.3 session resumption, optionally with 0-RTT for idempotent requests, or HTTP/3 which combines transport and TLS setup
Resumption skips certificate work and 0-RTT lets data go with the first flight; QUIC merges the transport and crypto handshakes into 1 RTT. 0-RTT data can be replayed, so it is only for idempotent requests. Larger keys make the handshake slower. Nagle affects small writes on an open connection, not setup. A shorter TTL causes more DNS lookups, not fewer.
An interviewer asks: a page in Mumbai takes 1.8 s to first byte from your us-west origin. Break down where that time likely goes and what you would change first.
Show answer
Answer
Start with RTT (around 250 ms Mumbai to us-west). Cold path: DNS (maybe 1 RTT to a resolver plus authoritative), TCP 1 RTT, TLS 1 RTT, request 1 RTT, so roughly 1 s before server time. Add redirects (http to https, apex to www) at 1 RTT each, and slow server or DB work.
Fixes in order: CDN or edge termination near users (handshakes become local), remove redirects, connection reuse, TLS 1.3 or HTTP/3, then a regional deploy or edge cache for dynamic parts. Measure with timing breakdowns (curl -w or browser timing) before guessing.
