One request, many servers — who answers it?
A load balancer sits between clients and a fleet of servers. For every single request it makes exactly one decision: which server handles it. Get that decision right, consistently, and no single server buckles while others sit idle. The simulator below runs that decision live, under seven common algorithms.
Traffic simulator
Weight and speed matter most for Weighted Round Robin, Weighted Least Connections, and Least Response Time. Try slowing one server down, or taking it offline, and watch how each algorithm reacts.
How each algorithm decides
Every algorithm answers the same question — which server gets this request — using a different signal: order, capacity, live load, latency, or the client's own identity.
Round Robin
Requests are handed to servers in a fixed rotating order — server 1, then 2, then 3, then back to 1 — regardless of how busy each one currently is.
Best for: a fleet of identical servers handling requests of roughly equal cost.
Watch out: a server that's slower or already backlogged still gets its turn just as often as everyone else.
Weighted Round Robin
Same rotation as round robin, but each server carries a weight representing its share of capacity — a server with weight 3 gets three turns for every one turn a weight-1 server gets.
Best for: mixed hardware, e.g. one box with twice the CPU of the others.
Watch out: weights are set once, by hand — they don't adjust when a server's real-time load changes.
Least Connections
Each new request goes to whichever server currently holds the fewest open connections.
Best for: long-lived or variable-length connections — WebSockets, streaming, slow queries — where duration varies a lot.
Watch out: connection count is a proxy for load, not a perfect one; a server can hold few connections that are each individually expensive.
Weighted Least Connections
Divides each server's connection count by its weight before comparing, so a high-capacity server can carry proportionally more connections before it's considered busy.
Best for: mixed-capacity fleets serving long-lived connections — capacity-aware and load-aware at once.
Watch out: still depends on someone setting sensible weights by hand.
Least Response Time
Sends the request to whichever server has answered fastest recently — a live estimate of who's least loaded right now, rather than a fixed number.
Best for: latency-sensitive services, where response time is the thing users actually feel.
Watch out: needs continuous latency probing to stay accurate; a brief blip can look like a trend.
IP Hash
Runs the client's IP address through a hash function to deterministically pick the same server every time that client connects.
Best for: session affinity ("sticky sessions") — keeping a shopping cart or login on the server that already holds its state.
Watch out: uneven if a few IPs generate most of the traffic (e.g. behind a shared NAT), and rebalances awkwardly when servers are added or removed.
Random
Picks a server purely at random for each request, with no memory of past decisions.
Best for: very large fleets of near-identical servers, where randomness converges to a fair spread with far less bookkeeping than round robin.
Watch out: over a small fleet, chance can bunch several requests onto one server in a row.
At a glance
No algorithm wins on every axis — the right choice depends on what your servers and your traffic actually look like.
| Algorithm | Adapts to real-time load | Session affinity | Needs manual weights | Typical use |
|---|---|---|---|---|
| Round Robin | No | No | No | Uniform servers, uniform requests |
| Weighted RR | No | No | Yes | Mixed-capacity servers |
| Least Connections | Yes | No | No | Variable-length connections |
| Weighted LC | Yes | No | Yes | Mixed capacity + variable connections |
| Least Response Time | Yes | No | No | Latency-sensitive services |
| IP Hash | No | Yes | No | Sticky sessions |
| Random | No | No | No | Large, uniform fleets |