A load balancer distributes incoming traffic across multiple servers; L4 balancers route on IPs and ports, L7 balancers route on HTTP paths and headers.
If you have thirty seconds to answer
A load balancer distributes incoming requests across a pool of servers and stops sending traffic to instances failing health checks. Layer 4 balances on IP and port, which is fast and protocol-agnostic; layer 7 reads the request and can route by path, header or cookie, which is what canary releases and per-tenant routing need. The parts worth defending in an interview are the distribution algorithm, the health check, and what happens to in-flight connections when an instance goes away.
Definition
A load balancer is a component that distributes incoming requests across a pool of servers so no single machine becomes a bottleneck or single point of failure. Balancers health-check their backends and stop routing to failed instances, which is what turns a fleet of interchangeable servers into a fault-tolerant service.
The important distinction is the layer they operate at. A Layer 4 (transport) balancer sees only IPs and ports, spreading TCP/UDP connections cheaply. A Layer 7 (application) balancer parses HTTP, so it can route by URL path or header — /api/video to the video service, a percentage of traffic to a canary — at the cost of more processing per request. Load balancing works best when the servers behind it are stateless, so any server can handle any request.
How it comes up in interviews
Every design has one, so interviewers probe depth instead: L4 vs L7 (content-aware routing is the L7-only capability), why stateless app servers make balancing trivial, and what the balancer itself does when it fails (typically redundant pairs with health-checked failover).
What separates a strong answer
Common answer
Drawing a load balancer box in front of the application tier and never mentioning it again.
What lands
Treating the health check as the interesting decision: "a deep check that pings the database pulls every instance out at once during a database blip, so the check stays shallow and dependency failure is handled by a circuit breaker instead."
Load Balancer interview questions
The forms this comes up in, and what a complete answer covers.
Layer 4 or layer 7, and why?
Layer 4 forwards on IP and port without inspecting the payload: lower latency, works for any TCP protocol, and cannot make content-based decisions. Layer 7 terminates the connection and reads the request, which enables path-based routing, header-based canaries, per-tenant routing, request-level retries and TLS termination in one place. Most web architectures use layer 7 at the edge because those features are the reason the load balancer exists; layer 4 suits high-throughput non-HTTP traffic and cases where you must not terminate TLS.
Round robin or least connections?
Round robin is fine when requests cost roughly the same, which is often true for uniform API traffic. Least connections is better when request cost varies widely, because a server stuck on several slow requests stops receiving new ones — round robin would keep feeding it. If backends are heterogeneous, weight the algorithm by capacity. For cache locality or sticky sessions, consistent hashing on a key keeps a client landing on the same instance while limiting reshuffling when the pool changes.
How does the load balancer know a server is healthy?
Active health checks poll an endpoint on an interval and remove instances after a threshold of failures; passive checks observe real traffic and eject on errors. The design trap is depth: if the health endpoint checks the database, a brief database problem fails every instance simultaneously and the load balancer removes the entire fleet, converting a degradation into an outage. Keep the check shallow enough to test the instance itself, and handle dependency failure with circuit breakers and graceful degradation.
The load balancer is a single point of failure. What do you do about it?
Acknowledging it is most of the answer. In practice a managed load balancer is already a redundant fleet behind one address, but the reasoning still matters: you need multiple instances across availability zones, with DNS or anycast distributing across them and health-based failover. On the way out, instances should be drained rather than dropped — stop new connections, let in-flight requests finish within a timeout — otherwise every deploy produces a burst of errors that looks like an application bug.