Skip to main content
Load Balancinglesson 1 of 4 · 2 min read

What a Load Balancer Does

One address, many machines

A load balancer sits in front of a group of servers, shows the world one address, and hands each request to one of the machines behind it.

Your clients no longer know two things. Not how many servers you run, not which one answered them. You can add a machine, remove one, or replace all of them, and nobody reconfigures anything.

That one piece of indirection does four jobs. Spreading traffic is the obvious one, putting 10,000 requests a second across 20 machines so none of them melts.

It is also how you stay available, because a server that fails its health check stops receiving traffic. It is how you deploy, because a rolling restart just drains one machine at a time while the others carry the load. And it is usually where HTTPS ends, decrypting once at the edge so your machines speak plain HTTP to each other inside the network.

The cheap substitute is worth resisting. DNS round robin hands out several addresses for one hostname and does spread traffic, badly, because DNS has no idea a server just died.

Cached records mean clients keep hammering a dead machine until the record expires, which takes minutes. A real balancer notices in seconds and decides per request.

What happens when the balancer dies

Ask the obvious question next: what happens when the balancer dies? Answer it with layers. You run them in pairs, either active-passive sharing an address that moves on failure, or active-active behind DNS.

Managed ones like an AWS load balancer do this for you, presenting one name backed by spare capacity in several data centres. In an interview a single sentence saying your balancer is redundant too is plenty, and skipping it invites the follow-up you did not want.

the shape of it
Clientssee one addressLoad balancerHA pairServer 1Server 2Server 3just added1. HTTPS2. forward2. forward2. and the new one3. response
step 1 of 3
Clients talk to one stable address while the balancer picks a backend for every request.

Worked example

Meera's startup runs one API server, and it dies during a demo to their biggest prospect. The quick fix, three servers with DNS round robin, backfires within a month: when server 2 kernel-panics, a third of clients keep resolving to its IP for up to 10 minutes because resolvers cached the record. The real fix is an AWS ALB: one hostname, three registered targets, health checks every 10 seconds. The next time a server dies, the ALB stops routing to it in about 25 seconds and the other two absorb the load; nobody outside the team notices. Deploys change too. She rolls one target at a time with connection draining, and the 2 am deploy window quietly becomes 2 pm.