Round robin is a load balancing algorithm that assigns each new request or connection to the next server in a fixed, repeating order. In networking and load balancing, it is the simplest and most common default distribution method: with three servers A, B and C, requests go to A, B, C, A, B, C and so on, so that each server receives an equal share of new work.
Its strength is that it needs no knowledge of server load and almost no computation, which makes it predictable and fast. Its weakness follows from the same property: round robin assumes that servers and requests are roughly equal, and it distributes poorly when they are not.
How round robin distributes requests
Round robin distributes requests by keeping a pointer into the list of healthy servers and advancing it by one for every new connection or request. When the pointer reaches the end of the list, it returns to the beginning, which gives the method its circular name.
The unit being distributed matters. A layer 4 load balancer applies the rotation to new TCP connections, so a single long-lived connection stays on one server. A layer 7 load balancer can rotate individual HTTP requests, even within one client connection, which produces a much finer and more even spread.
Health checks are an essential companion. The rotation includes only servers that pass their checks; when a server fails, it is removed from the list and its share is redistributed among the remaining servers until it recovers.
Variants of round robin
Several variants extend the basic rotation to handle unequal servers or more realistic traffic. The table compares the most widely implemented ones.
| Variant | How it works | Best suited for |
|---|---|---|
| Plain round robin | Strict rotation, one request each | Identical servers and similar requests |
| Weighted round robin | Servers receive shares proportional to weights | Servers with different capacity |
| Smooth weighted round robin | Interleaves weighted picks instead of bursts | Avoiding consecutive hits on one server |
| DNS round robin | Rotates the order of multiple address records | Coarse distribution without a load balancer |
| Dynamic or slow-start round robin | Ramps new servers up gradually | Servers with cold caches after deployment |
With weighted round robin, a server with weight 3 receives three requests for every one sent to a server with weight 1. Smooth implementations spread those three picks across the cycle, so the larger server is not hit by three requests in a row, which reduces short queues.
Round robin compared with other algorithms
Round robin is a static algorithm, while its main alternatives react to the current state of the servers or to properties of the client. Choosing between them depends on how uniform the workload is.
| Algorithm | Decision based on | Strength | Weakness |
|---|---|---|---|
| Round robin | Fixed rotation | Simple, even, predictable | Ignores actual load |
| Least connections | Current open connections | Adapts to long requests | Needs shared state |
| Least response time | Measured latency and load | Favors fast servers | Can oscillate under bursts |
| Random with two choices | Better of two random picks | Scales well across many balancers | Less predictable |
| Hash-based | Client address or key | Keeps clients on one server | Uneven with few clients |
Round robin and sticky sessions are often combined: the rotation decides where a new client goes, and a cookie or affinity table then keeps that client on the same server. Stickiness reduces the evenness of round robin, especially when a few clients generate most of the traffic.
When round robin is the right choice
Round robin is the right choice when servers are equivalent and requests are short and similar, as with stateless web front ends or API services behind a load balancer. In those conditions it performs as well as more complex methods, and its behavior is easy to reason about.
| Situation | Recommended method | Reason |
|---|---|---|
| Identical stateless web servers | Plain round robin | Even spread with minimal overhead |
| Mixed server sizes in one pool | Weighted round robin | Shares follow capacity |
| Long uploads or database queries | Least connections | Accounts for uneven request duration |
| Session data stored on the server | Round robin with affinity | Clients keep their session |
| Simple redundancy without a balancer | DNS round robin | No extra infrastructure |
Limitations and common mistakes
The central limitation is that round robin counts requests, not work. If every tenth request is a heavy report that takes several seconds, and the rotation happens to align with it, one server can receive all heavy requests while others stay idle.
- DNS round robin is not real load balancing: resolvers and clients cache records, often for minutes, and keep sending traffic to a failed address because DNS has no health checks.
- Connection-level rotation with HTTP/2 or gRPC can concentrate traffic, because one client sends many requests over a single persistent connection.
- Several independent balancers each keep their own pointer, so the overall spread is even only on average.
- Adding a server with a cold cache to a full rotation can overload it immediately; slow start avoids this.
Monitoring per-server request rates and response times reveals whether the even request count actually produces even load. When it does not, switching to weighted or least-connections distribution is usually a one-line configuration change.
The idea in brief
Round robin is like dealing cards around a table. Each player gets one card in turn, and when the dealer reaches the last player, the dealing starts again from the first. Nobody is skipped and nobody gets two cards in a row.
A load balancer does the same with visitors to a website, sending each new one to the next server in line. This works very well when all servers are equally strong and all visitors ask for similar things. When some requests are much heavier than others, a smarter method that looks at how busy each server is may share the work more fairly.
A practical scenario
An online ticket shop runs its storefront on four identical application servers behind a layer 7 load balancer configured for plain round robin across HTTP requests. Session data is kept in a shared cache, so any server can handle any request, and each server receives about 25 percent of the traffic during a sales launch.
Later, the team adds two larger servers with twice the CPU capacity. Under plain rotation, the new servers stay half idle while the old ones run hot. The team switches to weighted round robin with weights of 1 for the original servers and 2 for the new ones, and enables slow start for 60 seconds. Response times become uniform across all six servers during the next launch.