What it's for
- Spread requests so no single server becomes the bottleneck.
- Keep answering when one machine fails, by sending traffic elsewhere.
- Grow by adding ordinary servers instead of buying a bigger one.
Good to know
Round-robin is simple but blind: it treats a fast server and a slow one as equal. Least-connections watches how busy each server actually is, which is why the fast server ends up doing more of the work here. Real balancers also terminate TLS, pin sessions and retry failed requests; none of that is shown.
How it works, step by step
Why the steps go in this order
- One server is the start of every system — and the first thing traffic outgrows.
- A queue hides the overload for a moment, then drops make it visible: more requests in than work out loses some.
- Round-robin spreads arrivals evenly, which already fixes the queue — until servers differ.
- Least-connections watches real busyness, so the fast server earns more of the work.
- Health checks make failure ordinary: the balancer notices and deals around the dead server.
Before you rely on it
This is a teaching model. Arrivals are fixed, service times are averages, and there is no network jitter, no retries and no consistent hashing. For real designs, read the current NGINX, HAProxy or your cloud balancer's documentation.