Load Balancing

In technical terms

L4 balances on connections (fast, transport-level, blind to paths); L7 balances on requests (routing by path/header/cookie, TLS termination, WAF adjacency). Algorithms: round-robin (uniform cost assumption), least-connections/latency (uneven work), IP or cookie hashing (session locality without state). Health checks detect process liveness, and must be application-shaped (a pool-wedged server answers TCP perfectly); connection draining keeps deploys clean.

Why it appears in interviews

Every availability story begins at the front door; the panel uses it to check whether health checks in your answers would actually catch your real failure mode.

The common misconception

The balancer makes you highly available. It is also a chokepoint unless itself redundant (DNS failover, anycast, cloud-managed pairs); and round-robin presumes equal work, which long-lived streaming requests immediately violate.

Trade-offs & when it hurts

Sticky sessions simplify in-process state and caches but wreck rebalancing the day you scale; hash-based affinity is the compromise. L7 buys routing intelligence at CPU and one more hop of failure surface; managed cloud balancers trade control for not paging on them at 3am.

How to show it in an interview

Prove operational depth through the health check: “A TCP probe never catches the instance whose connection pool is wedged. The check hits a readiness endpoint that acquires a pool connection with a 100ms timeout, so one hung box leaves rotation in two intervals while the deploy drains connections instead of cutting them.” That answer is lived experience; nothing before it is.

Questions this concept earns

• The process is up but wedged: how fast does your cluster know, and what do users see meanwhile?
• Round-robin across mixed instance sizes: what breaks first, and what replaces the algorithm?
• One balancer, every request: what is the failure plan, and does it actually need DNS?

Related