Load Balancer Algorithm Visualizer

A load balancer distributes incoming network requests across multiple backend servers so no single server becomes a bottleneck. It improves availability (if one server fails, others take over), scalability (add servers to handle more traffic), and performance (requests go to the least-busy or fastest server). Almost every production web service with more than one server uses a load balancer.

Round Robin is the right default when all your servers have similar hardware specs and your requests are roughly uniform in cost (e.g. serving static files or lightweight API calls). It requires no state tracking and has near-zero overhead, making it ideal for high-throughput scenarios where simplicity matters. Avoid it when requests vary widely in processing time, as a slow request will monopolise a server while others sit idle.

Least Connections picks the server with the fewest active connections at the moment of routing. Least Response Time goes further by factoring in average response latency—it favours a server that is fast even if it has more connections, over a slow server with few connections. Use Least Connections for CPU-bound workloads; use Least Response Time for I/O-bound or variable-latency services.

IP Hash routes each client IP to the same backend server every time (session affinity / sticky sessions). This is essential when server-side session state is stored in memory and not shared across instances—for example, legacy PHP or Node apps that store login sessions locally. If your app stores sessions in Redis or a database, you do not need IP Hash and can use any stateless algorithm.

You assign each server a weight (e.g. 1, 2, 4). The load balancer expands this into a request pool proportional to weights, then cycles through it. A server with weight 4 gets four requests for every one sent to a weight-1 server. This is useful in mixed-hardware environments—for example, if Server A has twice the CPU cores of Server B, give it weight 2 to utilise its extra capacity.

The Uniformity Score (0–100%) measures how evenly requests are spread across all servers, using the coefficient of variation of per-server request counts. A score of 100% means every server received exactly the same number of requests (perfect distribution). Scores below 80% indicate meaningful imbalance, which may signal that an algorithm is a poor fit for the simulated workload or server configuration.