Three algorithms. One dial to crash it. Watch how each strategy spreads load — and where each one breaks.
What problem are we solving?
A single server can only handle so many requests before it melts. The naive fix — buy a bigger box — hits a ceiling fast. A load balancer sits in front of N identical servers and decides, for every incoming request, which server should handle it. The hard part isn't the routing: it's doing it fairly, without a single point of failure, and without sending traffic to a dead server.
Live simulation
updates every 1s
20 req/s incoming
LB · round-robin
Tap any server to mark it failed. Capacity per server: 50 req/s.
Controls
20 req/s
4
Failed servers
None. Tap a server in the canvas to fail it.
Live metrics
Total requests served0+0 this tick
Failed requests0
Avg latency0 ms
Cluster utilization10%
Healthy servers4/4
Per-server load
S1
0/s
S2
0/s
S3
0/s
S4
0/s
What just happened?
20 req/s are being distributed across 4 healthy server(s) using the round-robin algorithm. Each server is running at ~10% of its 50 req/s capacity.
Try this
Traffic suddenly doubles
Black Friday. Your marketing team just launched a flash sale. Hit the button to double the current traffic rate and watch what happens to per-server utilization and average latency.
When traffic doubles, what is the cheapest way to keep latency under 100ms — add more servers, switch algorithms, or shed non-essential traffic?
Key takeaway
A load balancer's job is not just to send traffic — it's to send traffic only to servers that can handle it. Health checks + algorithm choice + capacity headroom are the three levers. None of them alone is enough; round-robin on a cluster with a dead server is worse than random routing that knows who's alive.
