I Built a Load Balancer Lab: Round-Robin vs Least-Connections vs IP-Hash, Live

Everyone can name the load-balancing algorithms. Far fewer can feel the difference — "round-robin ignores load, least-connections adapts" stays abstract until you watch a slow server pile up under one and stay balanced under the other. So I built a lab where you send live traffic and watch it happen.

▶ Live demo: https://dev48v.github.io/load-balancer-lab/
Source (single file, zero deps): https://github.com/dev48v/load-balancer-lab

Requests take a random time to finish, so active connections build up — which is exactly what separates the algorithms. Pick one, send a burst, watch the per-server counts.

The five, and what actually differs

• Round Robin — cycle through servers in order. Perfectly even by count, but blind to load: point it at servers with uneven request durations and one quietly backs up while its turn keeps coming.
• Weighted Round Robin — bigger servers (higher weight) get proportionally more. Bump a weight and watch its share grow.
• Least Connections — send to the server with the fewest in-flight requests. This is the one that adapts — a backed-up server stops getting new traffic until it drains.
• Random — pick at random. Zero state, and surprisingly close to round-robin at volume (the law of large numbers does the balancing).
• IP Hash (sticky sessions) — hash(clientIP) % servers. The same client always lands on the same server, so you can keep a session pinned without shared session storage:

hash("203.0.113.7") % 4  →  server 2   (always, until the pool changes)

Click "send" repeatedly on IP Hash and the same IP keeps hitting the same server — then take that server down and watch it rehash to another.

The health-check bit people forget

A load balancer isn't just distribution — it's removing dead backends. Take a server down in the lab and it drops out of the rotation immediately; every algorithm reroutes around it, and IP-hash clients that were pinned to it get rehashed. Bring it back and it rejoins. That reroute-on-failure is half the reason you put a load balancer in front of anything.

Why a lab

You can read the nginx upstream docs and still be fuzzy on when least_conn beats the default round-robin. Watching one server's connection bar climb under round-robin, then flatten the instant you switch to least-connections, turns the docs into intuition.

One index.html, no build, works offline. If it made load balancing click, a star helps others find it: https://github.com/dev48v/load-balancer-lab