Round Robin vs Least Connections Load Balancing
Round robin vs least connections load balancing compared — how each works, when to use them, and the key tradeoffs.
Expected Interview Answer
Round robin distributes requests to backend servers in a fixed rotating order regardless of current load, while least connections sends each new request to whichever server currently has the fewest active connections — least connections handles uneven request durations far better, but round robin is simpler and sufficient when requests are uniform and servers are equally capable.
Round robin is stateless with respect to server load: server A, then B, then C, then back to A, in a strict cycle, so it assumes every request takes roughly the same amount of time to process. That assumption breaks down when some requests are cheap (a static asset) and others are expensive (a heavy database query), because round robin can pile several slow requests onto one server just because it was next in line. Least connections instead tracks how many requests each backend is currently handling and always routes to the least-loaded one, which self-corrects for uneven request costs and naturally adapts if one server temporarily slows down. The tradeoff is that least connections requires the load balancer to maintain live connection-count state per backend, which is slightly more overhead than round robin’s stateless counter, and it can behave suboptimally if connection duration doesn’t correlate with actual server load (e.g., long-lived idle websocket connections).
- Round robin is simple, stateless, and predictable for uniform workloads
- Least connections adapts automatically to uneven request durations
- Least connections self-corrects when one backend temporarily slows down
- Choosing correctly avoids overloading a server that “happened to be next”
AI Mentor Explanation
Round robin is like a coach sending net-session batters to bowling machines strictly in a fixed rotation, regardless of how long each batter’s session takes — if one batter camps at machine 2 for twenty minutes, the next batter is still sent there and has to wait. Least connections instead sends the next batter to whichever machine currently has no one using it, adapting to actual busy-ness. When sessions vary wildly in length, least connections keeps queues far shorter than blind rotation ever could.
Step-by-Step Explanation
Step 1
Round robin request
The load balancer maintains a pointer that advances through the server list, sending each new request to the next server in the cycle.
Step 2
Least connections request
The load balancer instead checks live active-connection counts per server and routes to the current minimum.
Step 3
Behavior under uniform load
With similar request costs and server capacity, both algorithms produce nearly identical, evenly balanced distributions.
Step 4
Behavior under skewed load
With uneven request durations, least connections self-corrects while round robin can pile slow requests onto one server.
What Interviewer Expects
- Clear, accurate definitions of both algorithms
- Identifies that request duration variance is the key deciding factor
- Notes least connections requires live per-server state, round robin does not
- Can give a concrete scenario where each is the better choice
Common Mistakes
- Claiming round robin is always worse — it is fine for uniform, short-lived requests
- Thinking least connections accounts for CPU/memory load, not just connection count
- Assuming both algorithms require the same amount of load balancer state
- Forgetting weighted variants of both exist for heterogeneous server capacity
Best Answer (HR Friendly)
“Round robin just takes turns sending requests to each server in a fixed order, which works fine when every request is roughly the same size. Least connections is smarter — it always sends the next request to whichever server is currently least busy, which matters a lot when some requests take much longer than others, since it keeps every server evenly loaded instead of letting one get stuck with a pile of slow work.”
Code Example
from itertools import cycle
servers = ["A", "B", "C"]
rr_pool = cycle(servers)
active = {s: 0 for s in servers}
def round_robin():
return next(rr_pool)
def least_connections():
target = min(active, key=active.get)
active[target] += 1
return target
# Simulate: server "A" gets a long-running request first
long_request_server = round_robin() # "A" is busy for a while
active[long_request_server] += 1
# Next request under round robin still goes to "B" regardless of load
print("round_robin ->", round_robin()) # "B"
# Next request under least_connections avoids the busy server "A"
print("least_connections ->", least_connections()) # "B" or "C", never overloaded "A"Follow-up Questions
- When would round robin actually outperform least connections in practice?
- How does weighted least connections combine both ideas?
- What per-server state must a load balancer track for least connections?
- How do these algorithms interact with health checks and unhealthy backends?
MCQ Practice
1. Which algorithm is stateless with respect to current server load?
Round robin cycles through servers in fixed order without checking current load; least connections is load-aware.
2. Least connections is most advantageous when:
Least connections self-corrects for uneven request durations by always routing to the currently least-busy server.
3. What extra state does least connections require compared to round robin?
Least connections must track how many active connections each backend currently holds to route correctly.
Flash Cards
Round robin in one line? — Sends each request to the next server in a fixed rotating order.
Least connections in one line? — Sends each request to the server currently holding the fewest active connections.
When does round robin fall short? — When request durations vary widely — it can pile slow requests onto one server.
What state does least connections need? — Live per-server active-connection counts, updated as connections open and close.