A load balancer sits in front of a pool of servers and decides which one handles each incoming request. The algorithm it uses to make that choice determines whether traffic spreads evenly, whether slow servers get overwhelmed, and whether a user stays pinned to the same backend. Choosing the right algorithm is less about raw speed and more about matching the distribution strategy to how your requests actually behave.
What changed in 2026
- Adaptive, latency-aware balancing spread. More balancers now route based on live signals — response time, queue depth, error rate — instead of static rules alone.
- Service meshes moved balancing to the client. With sidecars and mesh proxies, load-balancing decisions increasingly happen close to the caller rather than at a single central box.
- Power-of-two-choices gained ground. This lightweight approach — sample two servers, pick the less busy — became a popular default for its excellent balance-to-overhead ratio.
The core algorithms
- Round robin. Send each request to the next server in order. Simple and fair when servers and requests are uniform.
- Weighted round robin. Give bigger servers a larger share by assigning weights. Good for mixed hardware.
- Least connections. Route to the server with the fewest active connections. Better when request durations vary widely.
- Least response time. Route to the fastest-responding server. Adapts to real load, not just connection counts.
- IP hash. Hash the client address to always map a user to the same server. Useful for session stickiness.
- Power of two choices. Pick two servers at random, send to the less loaded one. Near-optimal spread with tiny overhead.
Algorithms compared
| Algorithm |
How it picks |
Best when |
| Round robin |
Next in rotation |
Uniform servers and requests |
| Weighted round robin |
By assigned weight |
Mixed server capacity |
| Least connections |
Fewest open connections |
Variable request length |
| Least response time |
Fastest replies |
Latency-sensitive traffic |
| IP hash |
Hash of client IP |
Session stickiness needed |
| Power of two choices |
Less busy of two random |
General-purpose default |
When to use which
Start with round robin if your servers are identical and requests are short and similar — it is predictable and cheap. Move to least connections when request durations vary, so long-running requests do not pile up on one box. Reach for least response time or power-of-two-choices when you want the balancer to react to real load rather than assume uniformity. Use IP hash only when you genuinely need stickiness, and prefer external session storage where you can, since it interacts badly with scaling and with rate limiting strategies.
Common pitfalls
- Round robin with uneven requests. A cheap "next server" rule sends a giant request to an already-busy box as easily as an idle one.
- Stickiness that blocks scaling. IP hash pins users to servers; when you add or remove servers, mappings shuffle and sessions can break.
- Ignoring health checks. Any algorithm routing to a dead or degraded server is useless. Pair balancing with active health checks and graceful draining.
- No slow-start. Slamming a freshly added server with full traffic can knock it over. Ramp it up.
FAQ
What is the most common load balancing algorithm?
Round robin is the classic default for its simplicity, but least connections and power-of-two-choices are widely used when request sizes vary.
What is the difference between least connections and least response time?
Least connections counts open connections; least response time measures how fast each server actually replies. Response time adapts better to real performance differences.
How does load balancing handle sessions?
Either with sticky routing (like IP hash) that pins a user to one server, or, better, by storing session state externally so any server can handle any request.
What is the difference between layer 4 and layer 7 load balancing?
Layer 4 balances by IP and port without inspecting content; layer 7 reads the request (like the URL path) and can route more intelligently at a higher cost.
Where to go next