Weighted Round Robin

The core mechanism of weighted round robin is the assignment of a static integer weight to each server in the pool. This weight represents its relative capacity or priority. A server with a weight of 3 will receive approximately three times the number of connections over a cycle compared to a server with a weight of 1. Weights are typically configured by a system administrator based on hardware specifications like CPU cores, memory, or network bandwidth.

Unlike dynamic algorithms, weighted round robin uses a predictable, cyclic sequence. The load balancer iterates through the server list in order. For each server, it sends a number of consecutive requests equal to its weight before moving to the next server. This creates a fixed distribution pattern that is easy to model and debug. For a pool with weights [3, 1, 2], the request sequence over one full cycle would be: A, A, A, B, C, C.

This algorithm is specifically designed for environments with non-identical servers. It prevents underutilization of powerful servers and overloading of weaker ones, which is a key limitation of standard round robin. In a heterogeneous fleet of Autonomous Mobile Robots (AMRs), weights could be assigned based on battery capacity, maximum payload, or specialized tooling (e.g., a forklift AMR gets a higher weight for pallet-moving tasks).

Weighted round robin has minimal runtime computational cost. The algorithm maintains a simple counter or pointer to track its position in the cycle. There is no need to calculate real-time metrics like response times or active connection counts. This makes it extremely efficient for high-throughput systems where the overhead of decision-making must be negligible, such as in network packet switches or foundational load balancers.

A significant limitation is its static nature. The algorithm does not adapt to changing server conditions. If a high-weight server becomes slow or congested, it will continue to receive a disproportionate share of traffic until its weight is manually reconfigured. It does not account for:

• Current server load or CPU utilization
• Network latency to the server
• Varying request processing complexity This makes it unsuitable for environments where server performance fluctuates dynamically.

Weighted round robin is ideal for stable, predictable environments with known resource disparities.

• Network Load Balancers (Layer 4): Distributing TCP/UDP connections across backend servers with different hardware profiles.
• DNS Load Balancing: Assigning multiple IP addresses with different priorities (weights) in a DNS SRV record.
• Task Queues in Robotics: In a mixed fleet, a dispatcher might assign more simple transport tasks to low-cost, high-availability AMRs (weight=2) and fewer complex manipulation tasks to slower, specialized robotic arms (weight=1).
• Legacy System Integration: When integrating new, faster servers with older hardware in a pool.

In a warehouse with mixed autonomous mobile robots (AMRs) and manual forklifts, WRR assigns more pick-and-place tasks to higher-capacity AMRs. A system might assign a weight of 3 to a high-speed robot and 1 to a slower manual cart, ensuring the fleet's total throughput is maximized by leveraging each agent's inherent capability. This prevents underutilization of premium assets while ensuring all agents contribute.

An API gateway can use WRR to route requests to different versions of a microservice or to instances in different availability zones. For a canary deployment, the stable version may have a weight of 95 and the new canary version a weight of 5, allowing a controlled, proportional rollout of new code to a small subset of traffic for validation before a full cutover.

In a machine learning training cluster with heterogeneous GPUs (e.g., A100s and V100s), a job scheduler uses WRR to assign training jobs. An A100 (higher FLOPs) may have a weight of 8 and a V100 a weight of 3. The scheduler cycles through the GPU list, assigning more compute-intensive jobs to the A100s. This simple, predictable scheduling ensures high-value hardware is fully utilized, directly optimizing infrastructure cost control for AI workloads.

The foundational algorithm upon which weighted round robin is built. Round robin distributes requests sequentially and equally across all servers in a pool, treating each server as having identical capacity. It is a simple, stateless method but does not account for differences in server performance.

• Cyclical Distribution: Requests are assigned to Server A, then Server B, then Server C, and back to Server A.
• Use Case: Ideal for homogeneous server fleets where all instances have identical specifications and capabilities.

A dynamic load balancing algorithm that directs new requests to the server with the fewest active connections at that moment. Unlike static round-robin methods, it responds to real-time load.

• Real-Time Awareness: Continuously monitors the connection count on each backend server.
• Optimal for Long-Lived Connections: Particularly effective for protocols like databases or persistent websocket connections, where request duration varies significantly.

An advanced hybrid of weighted round robin and least connections. It selects the server with the lowest number of active connections, but normalizes this count by the server's assigned capacity weight.

• Formula: Effectively chooses the server with the smallest value of (Active Connections / Weight).
• Dynamic & Proportional: Provides the real-time responsiveness of least connections while respecting predefined server capacity tiers, making it highly efficient for heterogeneous, dynamic environments.

A deterministic load balancing algorithm that uses a hash function on the client's source IP address to select a backend server. This ensures session persistence, as all requests from a specific client IP are directed to the same server.

• Session Affinity: Crucial for stateful applications where user session data is stored locally on a server.
• Potential for Imbalance: Can lead to uneven load distribution if a small number of client IPs generate disproportionate traffic.

A critical orchestration mechanism used by load balancers to determine server availability. Periodic probes (e.g., HTTP GET, TCP SYN) verify if a server is operational before traffic is routed to it.

• Failure Detection: Automatically removes unhealthy nodes from the server pool (draining).
• Liveness vs. Readiness: Liveness probes check if the server is running; readiness probes check if it can accept traffic (e.g., warmed up, connected to DB).

A distributed hashing technique that minimizes reorganization when servers are added or removed from a pool. It maps both servers and requests onto a hash ring, ensuring only a fraction of keys need remapping during scaling events.

• Scalability: Essential for large, elastic caching systems (e.g., Redis clusters, CDNs) and distributed databases.
• Virtual Nodes: Uses multiple points ("vnodes") per physical server on the ring to ensure an even load distribution.