Load Balancer Interview & Revision

It distributes requests across multiple backend servers to increase throughput and availability, and provides a single stable entry point for clients.

L4 routes using IP/TCP/UDP metadata such as IPs and ports, without parsing the application payload; L7 understands the application protocol (commonly HTTP/HTTPS or gRPC) and can route on host, path, headers, or cookies.

Via periodic active health checks (e.g., GET /healthz) and/or passive monitoring of real request failures, using consecutive-failure/success thresholds to avoid flapping.

They pin a client to the same backend server so in-memory session state is preserved. Avoid them when possible in favor of a shared session store (Redis/DB), because affinity is a workaround that can create uneven load and a soft dependency on a specific backend.

Blue/Green (instant cutover, instant rollback, double infrastructure cost) or Canary (gradual traffic ramp, smaller blast radius, slower rollout) — both rely on the load balancer to shift traffic.

GeoDNS or anycast routes each user to their nearest healthy region; if a region's health checks fail, traffic automatically reroutes to the next-nearest healthy region.

New instances register with the load balancer once they pass health checks; on scale-in, instances are drained (stop receiving new requests, finish in-flight ones) before termination.

Layer an L4/anycast tier for raw connection volume and DDoS absorption, feeding an L7 tier for content-aware routing; use least-connections or least-response-time algorithms, aggressive but well-tuned health checks, TLS termination at the edge, and shared session state to avoid sticky sessions limiting distribution. Illustrative sizing (assumptions, not measurements): if one L7 node sustains 50,000 requests/s and you plan for 60% peak utilisation, you need 1,000,000 / (50,000 × 0.6) ≈ 34 nodes, so 35 with one spare. At an assumed 10 KB average response that is 1,000,000 × 10 KB ≈ 80 Gbit/s of egress, and with an assumed 50 ms average latency about 50,000 requests are in flight at once (Little's law: 1,000,000 × 0.05 s).

Why can't a Layer 4 load balancer route based on a URL path? Answer: Because it only sees IP addresses, ports and connection state; the URL path lives inside the HTTP payload, which an L4 balancer does not parse (and which may be encrypted end-to-end under TLS passthrough).

What's the difference between an unhealthy threshold and a healthy threshold in a health check config? Answer: The unhealthy threshold is how many consecutive failed probes remove a server from rotation; the healthy threshold is how many consecutive passes bring it back. Both exist to prevent flapping.

Why does IP hash give you a lightweight form of session affinity, and what's its main downside? Answer: Hashing the client IP maps it to the same server every time without cookies. The downside is skew: many users behind one NAT or proxy share an IP and pile onto one server, and pool changes remap clients.

What is connection draining, and why does skipping it cause visible errors during a deploy? Answer: Draining stops sending new requests to an instance and waits for in-flight ones to finish before shutdown. Skipping it kills requests mid-flight, which clients see as errors.

Name one advantage and one disadvantage of Blue/Green deployments compared to Canary. Answer: Advantage: instant cutover and instant rollback. Disadvantage: it needs a full parallel environment (about double the infrastructure during the switch) and shifts all traffic at once, so a bad release reaches everyone, unlike a canary's small blast radius.

Why is anycast-based failover faster than GeoDNS-based failover? Answer: Anycast failover is a routing decision (a withdrawn BGP announcement moves traffic), so it avoids DNS caching delays, though it still depends on BGP convergence. GeoDNS failover waits for cached answers to expire.