We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Load Balancing & Proxies
A load balancing algorithm that distributes requests to servers in sequential order, cycling through the list. Simple but ignores server capacity differences.
In short
Round robin is a load balancing algorithm that hands out incoming requests to a pool of servers one at a time in a fixed circular order, sending request 1 to server A, request 2 to server B, request 3 to server C, then looping back to A. It spreads traffic evenly by count without tracking how busy each server actually is.
In short
Round robin is a load balancing algorithm that hands out incoming requests to a pool of servers one at a time in a fixed circular order, sending request 1 to server A, request 2 to server B, request 3 to server C, then looping back to A. It spreads traffic evenly by count without tracking how busy each server actually is.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Round Robin across a run of lessons, not one page. These 4 alone are about 108 minutes of step-by-step reading, every one with a quiz.
How load balancers decide which server gets the next request. Round Robin, Weighted, Least Connections, IP Hash, and more.
How traffic actually gets spread across many servers, and what breaks when it does not.
How a GSLB decides which region a user reaches, and why the decision takes minutes to arrive even when it is made in microseconds.
Using DNS to distribute traffic across servers, the simplest form of global load balancing.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Load Balancer Algorithmspay once,
yours for life
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.
NGINX
Default load balancing method for upstream blocks, with weighted and least_conn as alternatives one config line away.
HAProxy
Ships roundrobin as a balance directive, including dynamic weight changes without a reload.
AWS Elastic Load Balancing
Classic and Application Load Balancers use round robin style distribution across registered targets in a target group.
Linux IPVS
The kernel layer 4 load balancer behind many setups offers rr and wrr schedulers used by tools like kube-proxy.
Plain round robin gives every server an equal number of turns regardless of its size. Weighted round robin assigns each server a weight so more capable servers get proportionally more requests. A server with weight 4 receives four requests for every one a weight 1 server gets, which lets you mix big and small machines in the same pool.
It is good when your servers are identical and your requests cost about the same, because it spreads traffic evenly with almost no overhead. It is a poor fit when requests vary widely in cost or servers differ in capacity, since it ignores how busy each server actually is. In those cases least connections or least response time usually performs better.
Round robin is static and picks the next server purely by arrival order, ignoring current load. Least connections is dynamic and sends each request to whichever server has the fewest active connections right now, so it adapts when some requests take much longer than others.
Round robin on its own only rotates through the list. To skip dead servers you pair it with health checks. Load balancers like NGINX and HAProxy mark a backend down when health checks fail and remove it from the rotation, then add it back once it recovers.
It is round robin applied at the DNS level. One hostname maps to several IP addresses, and the DNS server rotates the order it returns them so different clients connect to different servers. It is simpler than a load balancer but less reliable because DNS caching by resolvers and browsers can pin a client to one IP for a long time, and it does not detect server failures quickly.
Load Balancer
Distributes incoming traffic across multiple servers so no single server gets overwhelmed. Like a traffic cop directing cars to different lanes.
Consistent Hashing
A hashing technique where adding or removing servers only moves a small fraction of keys. Used by Amazon DynamoDB and Cassandra for data distribution.
DNS
The phonebook of the internet. Translates human-readable domain names (google.com) into IP addresses that computers understand.
Proxy
An intermediary server that sits between the client and the destination server. Forward proxies act on behalf of clients; reverse proxies act on behalf of servers.
Reverse Proxy
A server in front of your web servers that receives every request first, passes it to one of them and returns the answer. It handles TLS, load balancing, caching and routing, and hides the servers behind it.
DNS Record Types
Different types of DNS records map domains to resources: A records point to IPs, CNAME aliases one domain to another, MX routes email, TXT stores verification data.
This page explains the idea. The "Load Balancer Algorithms" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Load Balancer Algorithms lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Round Robin in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
