Least connections is a dynamic load balancing algorithm that sends each new connection to the backend server with the fewest active connections at that moment. In load balancing it is the standard choice when requests differ widely in duration, because it reacts to the real, current load of each server instead of distributing traffic in a fixed order.
The algorithm assumes that the number of open connections approximates server load. When that assumption holds, least connections keeps busy servers from receiving more work while idle ones wait, which reduces queueing and smooths response times across a server pool.
How least connections works in load balancing
A load balancer using least connections keeps a live counter of active connections for every healthy backend. When a new connection or request arrives, it compares the counters, selects the server with the lowest value, increments that counter, and decrements it again when the connection closes.
When several servers share the lowest count, the balancer needs a tie-breaking rule. Common implementations fall back to round robin among the tied servers, which prevents the first server in the list from receiving a disproportionate share during quiet periods.
What counts as a connection depends on the layer. In Layer 4 load balancing it is a TCP or UDP flow; in Layer 7 load balancing it may be an HTTP request or a backend connection in a pool. With HTTP/2 and connection reuse, one client connection can carry many requests, so many proxies count active requests or streams rather than raw TCP connections.
| Value | Meaning | Updated when |
|---|---|---|
| Active connections | Connections currently assigned and open | On connection open and close |
| Weight | Relative capacity set by the operator | On configuration change |
| Health status | Whether the server may receive traffic | On each health check result |
| Maximum connections | Optional cap per server | On configuration change |
Variants of the least connections algorithm
Plain least connections treats all servers as equal. Real pools often mix machines of different sizes, so most load balancers offer weighted and refined variants that adjust the comparison.
| Variant | Selection rule | Best suited for |
|---|---|---|
| Least connections | Lowest active connection count | Identical servers with varied request durations |
| Weighted least connections | Lowest ratio of connections to weight | Servers with different capacity |
| Least outstanding requests | Fewest in-flight requests at Layer 7 | HTTP services with connection reuse |
| Least response time | Combines connections with measured latency | Pools where server speed varies |
| Power of two choices | Pick two servers at random, take the less loaded | Very large pools and distributed balancers |
With weighted least connections, a server with weight 4 and 20 connections has a ratio of 5, while a server with weight 1 and 6 connections has a ratio of 6, so the larger server receives the next request even though it already holds more connections. The power of two choices variant is popular in distributed systems because each balancer instance needs only a small amount of shared state yet still avoids the worst imbalances.
Least connections compared with other algorithms
The main alternatives differ in whether they use live load information and whether they keep a client on the same server. The table summarizes how least connections relates to its closest neighbors.
| Algorithm | Uses live load | Session affinity | Main weakness |
|---|---|---|---|
| Least connections | Yes, connection counts | No | Connection count may not reflect real cost |
| Round robin | No | No | Ignores slow or overloaded servers |
| Weighted round robin | No, static weights | No | Cannot react to sudden load changes |
| IP hash | No | Yes, by client address | Uneven when clients sit behind shared NAT |
| Consistent hashing | No | Yes, by key | Hot keys overload single servers |
Round robin performs as well as least connections when requests are short and uniform, such as static file serving. The advantage of least connections appears with long-lived or variable connections: database proxies, WebSocket services, file uploads, streaming and APIs whose calls range from milliseconds to many seconds.
Configuring least connections in practice
Most load balancers support least connections with a single setting. In HAProxy it is the balance leastconn directive, and in NGINX the least_conn directive inside an upstream block. Cloud load balancers offer it as least outstanding requests or a similar named policy.
| Situation | Recommended choice | Reason |
|---|---|---|
| Long sessions such as WebSocket or database connections | Least connections | Balances by real concurrency |
| Short, uniform HTTP requests | Round robin | Simpler, equally effective |
| Servers of different sizes | Weighted least connections | Accounts for capacity differences |
| Application needs session state on one server | Sticky session or hashing | Least connections does not keep affinity |
| Many balancer instances without shared state | Power of two choices | Avoids coordination overhead |
Least connections pairs well with connection draining: when a server is removed for maintenance, it stops receiving new connections while existing ones finish, and the algorithm naturally redirects new traffic to the remaining servers.
Pitfalls and limitations
The algorithm is only as accurate as its load signal. A connection count says nothing about how expensive each connection is, and several practical effects can distort it.
- Thundering herd on new servers: a freshly added server has zero connections and may receive a sudden flood; slow start settings ramp its share gradually.
- Idle connections inflate counts: keep-alive connections that carry no traffic make a server look busy.
- Distributed balancers see partial counts: each instance knows only its own connections, so global balance is approximate.
- Unequal request cost: one heavy report query and one tiny status call count the same.
- Failing servers that reject quickly: a server returning errors closes connections fast, looks idle, and attracts even more traffic unless health checks remove it.
Combining least connections with active health checks, slow start and sensible connection limits addresses most of these issues in production systems.
Explained without jargon
Least connections works like choosing the checkout line with the fewest people in a supermarket. Instead of sending customers to each register in turn, the store sends each new customer to the register that is currently least busy.
This matters when some customers have full carts and others buy only one item. Counting who is already waiting keeps the lines shorter than a simple take-turns rule, although a line with two very full carts can still move slowly.
A typical use case
An online learning platform runs a live chat and notification service over WebSocket on six identical servers. Students stay connected for anywhere from a few minutes to several hours. With round robin, one server accumulated thousands of long-lived sessions after a morning lecture, while others served mostly short visits.
The operations team switches the load balancer to least connections with a slow start of 60 seconds for newly added servers. During the next exam period, when concurrent connections rise sharply, the six servers stay within a few percent of each other in active sessions.
Memory use becomes predictable, and the team can add a seventh server during peak hours without overwhelming it. The outcome shows that balancing by current concurrency fits long-lived connections far better than distributing them in a fixed rotation.