Load Balancing Explained

One server can only handle so much. When traffic grows past that, you have two choices: a bigger server (there's a ceiling), or more servers working together. The second is how the web actually scales — and the thing making it possible is a load balancer.

What a load balancer does

A load balancer sits in front of a pool of servers and distributes incoming requests across them, so the work is shared instead of dumped on one machine.

Traffic ──► Load balancer ──► Server 1
                           ├─► Server 2
                           └─► Server 3

It does two jobs at once: spread the load (so no server is overwhelmed) and route around failures (so a dead server doesn't take requests).

Why it matters

Benefit	What it gives you
Scale	Add servers to handle more traffic — horizontally
Reliability	One server dies, traffic shifts to the healthy ones
Zero-downtime deploys	Update servers one at a time behind the balancer
Even performance	No single server becomes the bottleneck

That second row is huge for reliability: with a load balancer doing health checks, a crashed server is simply removed from rotation, and users never notice.

How it decides where to send traffic

Load balancers use an algorithm to pick which server gets each request:

Method	How it chooses
Round robin	Each server in turn, evenly
Least connections	The server with the fewest active requests
Weighted	Bigger servers get a larger share
IP hash	Same client always to the same server (sticky)

Round robin is the simple default; "least connections" handles uneven request costs better.

Health checks: the reliability superpower

The feature that makes load balancing more than just sharing work is the health check. The balancer continuously checks each server (a ping or an HTTP health endpoint):

A load balancer only sends traffic to servers that pass their health check. When a server crashes or goes slow, it's automatically pulled from the pool — turning what would be an outage into an invisible non-event. This is also how you deploy with zero downtime: drain one server, update it, return it, repeat.

Where it lives

A load balancer is often the same layer as your reverse proxy — many tools (Nginx, cloud load balancers) do both. It's the front door that also happens to distribute the traffic that comes through it.

A monitoring note

A load balancer's health checks keep your internal pool healthy — but you still want external uptime monitoring on the public endpoint. Why? Because the balancer itself, its config, or every backend failing at once are things only an outside check catches. Internal health checks + external monitoring = full coverage.

The bottom line

	In one line
What	Distributes traffic across many servers.
Why	Scale horizontally + survive individual server failures.
How	An algorithm (round robin, least connections…) + health checks.
Bonus	Health checks enable zero-downtime deploys.

Load balancing is how the web scales past one machine and shrugs off server failures. Spread the traffic, health-check the pool, and a dead server becomes a shrug instead of an outage — just keep an external eye on the front door too.