Round-robin, weighted round-robin, least-connections, and IP hash — same request stream, four outcomes
This simulator sends the same stream of synthetic client requests through four different load-balancing algorithms — round-robin, weighted round-robin, least-connections, and IP hash — so you can directly compare how each one distributes traffic across a pool of backend servers. Send single requests or a burst of ten and watch the distribution chart and routing log update in real time.
Round-robin is the simplest load-balancing algorithm: each new request is sent to the next server in a fixed rotation, cycling back to the first server after reaching the last. It works well when every backend server has roughly equal capacity and requests are short-lived and stateless. Weighted round-robin extends this by assigning each server an integer weight reflecting its relative capacity — a server with weight 3 receives three times as many requests as a server with weight 1 over the long run, using a smooth interleaving (as modeled here) rather than sending all of one server's share consecutively.
Least-connections routes each new request to whichever backend server currently has the fewest active connections, rather than following a fixed rotation. This adapts naturally to servers with different processing speeds or requests with widely varying durations — a server that is slow to finish its current work accumulates connections and receives fewer new ones until it catches up. It requires the load balancer to track live connection counts per server, which is more state than round-robin needs but is standard in modern Layer 4/7 load balancers (NGINX, HAProxy, AWS ALB/NLB).
IP hash computes a hash of the client's source IP address (sometimes combined with the destination port) and uses the result to consistently select the same backend server for that client on every request — this is a form of session affinity ("sticky sessions") that works without needing a shared session store between servers. Its main drawback is uneven distribution if client IPs are not well spread (e.g., many users behind the same corporate NAT all hash to one server) and reduced flexibility if that server needs to be taken out of rotation, since evicting it changes the hash mapping for many clients at once.
There is no universally best algorithm — the right choice depends on whether your backend servers are homogeneous or not (favor weighted round-robin if not), whether requests are short and stateless or long-lived (favor least-connections for long-lived), and whether you need session affinity without shared session storage (favor IP hash or a cookie-based alternative).
A Layer 4 load balancer makes routing decisions based on IP address and TCP/UDP port only, without inspecting application data — fast and protocol-agnostic. A Layer 7 load balancer inspects the actual HTTP request (URL path, headers, cookies) to make smarter routing decisions, such as routing /api requests to one server pool and /static requests to another, at the cost of more processing overhead.
Health checks — periodic synthetic requests (e.g., an HTTP GET to /health) sent to each backend server. A server that fails a configurable number of consecutive health checks is automatically removed from the active pool until it passes checks again, preventing the load balancer from routing real traffic to a down or degraded server.
Yes — many production load balancers support a two-tier approach, such as weighted least-connections (combining server capacity weighting with live connection tracking) or consistent hashing with virtual nodes (which reduces the redistribution problem that plain IP hash has when the server pool changes size).
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.