Weighted round robin is a static load balancing algorithm that distributes requests across a pool of servers in rotation, giving each server a share of traffic proportional to an assigned weight. In load balancing, it extends plain round robin for pools whose members differ in capacity: a server with weight 3 receives three times as many new requests or connections as a server with weight 1.
The algorithm is simple, predictable and cheap to compute, which is why it is the default or a standard option in most load balancers, reverse proxies and service meshes. Its main limitation is that it does not observe actual server load; it trusts the weights, so it works best when requests are similar in cost and the weights reflect real capacity.
How weighted round robin distributes requests
Each backend server receives an integer weight, typically from 1 to a few hundred. Over one full cycle, whose length equals the sum of all weights, every server receives exactly as many requests as its weight. With servers A, B and C weighted 5, 1 and 1, a cycle contains seven requests: five to A and one each to B and C.
The order within the cycle depends on the implementation. A naive version sends all of A’s requests in a row and then moves on, which creates short bursts on the heavy server. Smooth weighted round robin, used by several popular proxies, interleaves the choices so that the heavy server’s requests are spread evenly through the cycle.
| Variant | Order within one cycle | Burst behavior |
|---|---|---|
| Naive weighted round robin | A A A A A B C | Five consecutive requests to A |
| Smooth weighted round robin | A A B A C A A | Requests to A interleaved |
| Interleaved weighted round robin | A B C A A A A | Rounds by weight threshold |
In the smooth variant, each server keeps a current value. On every selection, each current value grows by the server’s weight, the server with the highest value is chosen, and the total of all weights is subtracted from the chosen server’s value. This produces an even pattern with very little state.
Choosing and setting weights
Weights should express relative capacity, not absolute numbers. Only the ratios matter: weights of 2, 4 and 6 behave exactly like 1, 2 and 3. Good weights come from load testing or production metrics such as requests per second at an acceptable latency, rather than from hardware specifications alone.
| Situation | Weight approach | Reason |
|---|---|---|
| Mixed hardware generations | Higher weight for newer servers | More cores and faster processing |
| Different instance sizes | Weight proportional to vCPU or memory | Capacity scales with size |
| Canary release | Small weight for the new version | Limit exposure to a few percent |
| Gradual migration | Shift weights step by step | Move traffic between data centers |
| Maintenance | Weight zero or drain | Stop new traffic to a server |
Weights also serve as a traffic-shifting tool. Setting a new version to weight 1 and the existing version to weight 19 sends about 5 percent of requests to the new version, which is a common way to run a canary deployment before a full rollout.
Weighted round robin compared with other algorithms
Weighted round robin belongs to the family of static algorithms, which decide without measuring the current state of the servers. Dynamic algorithms such as least connections react to load but need more information and coordination.
| Algorithm | Uses live load data | Handles unequal servers | Best fit |
|---|---|---|---|
| Round robin | No | No | Identical servers, uniform requests |
| Weighted round robin | No | Yes, through weights | Known capacity differences |
| Least connections | Yes | Indirectly | Long or uneven connections |
| Weighted least connections | Yes | Yes | Uneven servers and uneven requests |
| IP hash | No | Limited | Simple client affinity |
| Consistent hashing | No | Through virtual nodes | Caches and sharded data |
In practice, weighted round robin is a strong choice for short, uniform HTTP requests behind a Layer 7 load balancer. For long-lived connections such as WebSockets or database sessions, weighted least connections usually distributes load more fairly, because one long connection can occupy a server far longer than many short ones.
Operational behavior and pitfalls
The algorithm interacts with health checks, sticky sessions and multiple load balancer instances, and these interactions explain most surprises in production.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Heavy server overloaded | Weight overstates its capacity | Recalibrate from measured throughput |
| Uneven load despite correct weights | Requests differ greatly in cost | Switch to least connections |
| Distribution ignores weights | Sticky sessions pin clients | Accept skew or shorten affinity |
| Ratios off at small scale | Several balancers each keep their own cycle | Judge ratios over larger samples |
| New server flooded after start | Full weight applied immediately | Use slow start or ramp weights |
When a server fails a health check, the load balancer removes it from the rotation and the remaining servers absorb its share according to their weights. Capacity planning should therefore verify that the pool can survive the loss of its highest-weighted server, because that failure shifts the largest amount of traffic at once.
The idea in brief
Picture a restaurant with three cashiers. One is very fast and two are new. Instead of sending customers to each cashier in turn, the manager sends five customers to the fast cashier for every one sent to each new cashier.
Weighted round robin does the same with computer servers. Stronger servers get more work, weaker ones get less, and the order stays fair and predictable. It does not check how busy each server is at the moment. It simply follows the numbers it was given.
A practical scenario
An online shop runs its web application on four servers behind a reverse proxy. Two older servers handle about 400 requests per second each at acceptable latency, while two new servers handle about 800. The team assigns weights of 1 to the older servers and 2 to the new ones, so each new server receives a third of the traffic and each older server a sixth.
Later, a new release is deployed to one extra server with weight 1 against a total of 6 for the rest, sending roughly 14 percent of requests to it. Error rates stay normal for an hour, so the team raises its weight step by step and finally moves all servers to the new version, with no outage and no overloaded machine during the rollout.