Load Balancing Algorithms: Round Robin vs Least Connections

Load balancing algorithms decide how incoming traffic gets spread across a pool of servers, and the two most common ones work very differently: Round Robin sends each new request to the next server in a fixed rotation, while Least Connections sends each request to whichever server is currently handling the fewest active connections. Round Robin is simpler and assumes every request takes roughly the same effort. Least Connections is smarter when some requests hang around much longer than others.

What a load balancer actually does

A load balancer sits in front of a group of servers (often called a backend pool or upstream) and acts as the single entry point for clients. Instead of users connecting directly to one machine, they hit the balancer, which forwards each request to a healthy server. This gives you three big wins:

• Server load distribution: no single machine gets crushed while others sit idle.
• Higher availability: if one server dies, traffic keeps flowing to the rest.
• Easy scaling: you add or remove servers behind the balancer without changing how clients connect.

The "algorithm" is just the rule the balancer uses to answer one question over and over: which server gets this next request? The rest of this guide compares the two answers most teams argue about.

Round Robin explained

So what is Round Robin load balancing? It's the simplest strategy there is. The balancer keeps a list of servers and hands requests out in order, looping back to the top when it reaches the end. With three servers (A, B, C), the pattern is A, B, C, A, B, C, and so on.

It doesn't look at how busy any server is. It doesn't care whether a request is a tiny health check or a giant file download. It just counts and rotates.

Where it struggles is uneven workloads. Imagine request #1 is a 10-minute report export and request #2 is a quick lookup. Round Robin doesn't know the difference, so server A can be stuck grinding on the big export while server B finishes its small job and sits idle, yet the next slow request could still land back on A.

Least Connections explained

The Least Connections algorithm makes a smarter choice. Before routing each request, the balancer checks how many active connections every server currently holds and sends the new request to the one with the fewest. The idea: fewer open connections usually means that server has more room to work right now.

This naturally handles uneven request times. If server A is tied up with three long-running downloads and server B just finished its last job, Least Connections routes new traffic to B until things even out. No single machine gets buried under a pile of slow requests.

The tradeoff is a bit more bookkeeping. The balancer has to track live connection counts per server instead of just incrementing a counter, but on modern hardware that overhead is tiny compared to the routing benefit.

Round Robin vs Least Connections

One subtle gotcha with Least Connections: connection count isn't a perfect proxy for actual work. A server can hold many open but idle keep-alive connections and look "busy" when it isn't. For most real workloads it's still the better default when request times vary.

Adding weights to either algorithm

Real server pools are rarely identical. Maybe one box has 32 CPU cores and another has 8. That's where weighted load balancing comes in. You assign each server a weight, and the balancer sends traffic in proportion to that weight.

• Weighted Round Robin: a server with weight 3 gets three requests for every one request the weight-1 server gets.
• Weighted Least Connections: the balancer compares active connections relative to each server's capacity, so a bigger server is allowed to hold more connections before it's considered "full."

Weighted distribution is the go-to when your fleet is a mix of old and new hardware, or when you're gradually shifting traffic to a new server group during a rollout.

Sticky sessions and why they change things

Sticky sessions (also called session affinity) tie a specific user to a specific server for the duration of their session. Once you're routed to server B, you keep going back to B. Balancers usually do this with a cookie or by hashing the client's IP address.

Why bother? Some apps store session data (like a shopping cart or login state) in the server's local memory instead of a shared store. If a later request lands on a different server, that data isn't there and the user gets logged out or loses their cart.

Server failover and health checks

Now for the safety net. What is server failover? It's the balancer automatically rerouting traffic away from a server that's down or unhealthy, so users never notice the failure. Server failover is what turns a pool of ordinary servers into a system that stays online when one machine crashes.

It relies on health checks: the balancer periodically pings each server (often hitting a URL like /health or opening a TCP connection). If a server fails a set number of checks in a row, the balancer marks it as down and stops sending it traffic. When it starts passing again, it's added back into the rotation.

Both Round Robin and Least Connections work the same way here: an unhealthy server is simply removed from the pool of candidates, and the algorithm keeps routing among the survivors.

Which one should you pick

Here's the short decision guide most engineers follow:

• Pick Round Robin if your servers are similar and requests are short and predictable. It's simple, fast, and predictable.
• Pick Least Connections if request durations vary widely or you handle long-lived connections. It adapts to real-time load far better.
• Add weights to either one when your servers have different capacity.
• Add sticky sessions only if your app truly stores session state locally, and treat it as a temporary crutch, not a design goal.

Many production setups (NGINX, HAProxy, cloud load balancers) default to Round Robin because it's safe and simple, then switch to Least Connections once monitoring shows uneven server load. You can read how NGINX documents its load balancing methods and how HAProxy handles the same choices if you want to see real config options.

Frequently asked questions