Round Robin

Round robin is the simplest way to share traffic across a group of identical servers. You keep an ordered list of backends and a pointer. Each new request goes to whoever the pointer points at, then the pointer moves to the next server. When it reaches the end of the list, it wraps back to the start. That circular handoff is where the name comes from, borrowed from round robin tournament scheduling where every player takes a turn against every other.

The whole appeal is that it needs almost no state. The load balancer does not have to ask servers how loaded they are, count open connections, or measure response times. It just increments a counter. With four servers and a thousand requests, each server gets roughly two hundred fifty requests over time.

Round robin is a static algorithm. The decision of where a request goes depends only on its arrival order, not on anything happening in the system right now. That is its strength when you want predictable, low overhead distribution, and its weakness when servers are not equal or requests are not equal.

The core is a single integer index, often guarded so concurrent requests do not pick the same slot. A common implementation is next = (current + 1) % serverCount. With three servers indexed 0, 1, 2, the sequence of picks is 0, 1, 2, 0, 1, 2 and so on. NGINX, HAProxy, and the Linux IPVS kernel scheduler all ship round robin as a built in policy.

Weighted round robin extends the basic idea for servers of different sizes. You assign each backend a weight, say a beefy 16 core box gets weight 4 and a small 4 core box gets weight 1. The algorithm then hands the bigger box four turns for every one turn the small box gets, so traffic roughly matches capacity. NGINX writes this as server backend1 weight=4.

At the DNS layer there is also DNS round robin, where a single hostname resolves to multiple IP addresses and the DNS server rotates the order it returns them. Clients usually connect to the first address, so rotating the list spreads connections across machines. This is cruder because DNS caching by resolvers and browsers can pin a client to one IP for minutes or hours.

Reach for round robin when your backends are stateless, roughly identical in hardware, and your requests are roughly uniform in cost. A fleet of web servers behind a load balancer serving cacheable pages is the textbook fit. It is also a fine default while you are still small and have not measured a reason to do anything fancier.

The big trade-off is that it is blind to real load. If request 5 is a heavy report that pins server B for thirty seconds, round robin still cheerfully sends request 8 to that same busy server while server A sits idle. It also ignores server health beyond basic up or down checks, so a server that is up but slow keeps getting its full share. For uneven workloads, least connections or least response time algorithms usually do better because they react to current state.

Round robin does not provide session stickiness on its own. If a user logs in and their session lives only in server A memory, the next request landing on server B will not find that session. Teams solve this with sticky sessions based on a cookie or source IP, or better, by moving session state into a shared store like Redis so any server can handle any request and round robin stays free to rotate.

Picture an online store running four application servers behind a load balancer. NGINX is configured with upstream app { server app1; server app2; server app3; server app4; } which defaults to round robin. During a normal browsing flood, requests cycle app1, app2, app3, app4, app1, and the four boxes each carry about a quarter of the load with no coordination needed.

Now a Black Friday sale lands and checkout requests, which run a slow payment call and inventory update, start mixing in with light catalog views. Plain round robin keeps splitting by count, so a server that drew three checkouts in a row gets just as many new requests as an idle peer. The store would notice tail latency climbing on some boxes and typically switch the upstream to least_conn, which sends each new request to whichever server currently has the fewest active connections, smoothing out the uneven work.

This is the normal lifecycle. Round robin gets you off the ground with near zero configuration and predictable spreading, and you graduate to a load aware policy only once measurements show that request cost or server capacity has become uneven enough to matter.