Common Load‑Balancing Strategies and Their Reliability Analysis in Distributed Systems

In distributed systems, load balancing is a crucial component that distributes incoming requests to one or more nodes for processing. Load balancing can be implemented via hardware appliances (e.g., F5) or software solutions that run on the servers themselves.

Common load‑balancing strategies include:

1. Round‑Robin – Requests are assigned sequentially to each server, assuming equal capacity and statelessness. Its drawback is treating all nodes as identical, which may not reflect real‑world conditions. Weighted round‑robin adds a weight attribute per node, but weight tuning remains difficult.

2. Random – A server is chosen randomly for each request, also assuming equal node capability. Weighted random variants exist but are not detailed here.

3. Minimum Response Time – The average response time of each server is measured and the request is sent to the server with the smallest average. Because it relies on averaged values, it can be sluggish in reacting to rapid changes.

4. Minimum Connections (Least Connections) – The current number of active transactions on each candidate node is tracked, and the request is directed to the node with the fewest ongoing connections, providing a fast reaction to server load.

5. Hash – When backend nodes maintain state, a hashing method is used to map requests to specific servers; the article does not elaborate on this approach.

The article then discusses fault tolerance in distributed systems, illustrating with an example where a request must traverse four clusters (A, B, C, D). Cluster B is called three times and contains five servers. If one server in B fails, ideal availability would keep 4/5 of the requests unaffected.

Using round‑robin or random selection, the probability that a single request reaches a healthy node is 4/5, so the success probability for three sequential calls is (4/5)³ ≈ 0.512, far below the ideal 0.8.

With the least‑connections strategy, assuming a normal request takes 10 ms and the timeout is 1 s, a failed node’s service capacity is 1 while a healthy node’s capacity is 100. The probability of routing to the failed node becomes 1/(100·4+1)=1/401, giving a success probability of (400/401)³≈99.25%.

Generalizing, let p be the proportion of failed servers in a cluster. For round‑robin/random, the success probability after k calls is (1‑p)ᵏ. For least‑connections, with m total servers and a degradation factor q (service capacity of a failed node is 1/q of a healthy node), the probability of selecting a healthy node is (m‑1·q)/(m·q‑1), and the overall success probability is that value raised to the k‑th power.

Figures (included as images) illustrate how the success rate f(p) declines as the failure proportion p increases, and how the choice of strategy impacts reliability for different values of q and k.

The analysis shows that when p is small (e.g., ≤0.4), the success rate remains relatively stable, but larger p values cause a sharp drop. It also notes that if client‑side detection of backend errors is fast (q < 1), the failure rate can increase dramatically even with a small fraction of faulty nodes, necessitating additional protective mechanisms such as removing consistently failing nodes.

Finally, the article warns that least‑connections is unsuitable for client‑side load balancing when client concurrency is low, recommending random selection in such cases, and acknowledges that real‑world interactions among nodes can be more complex than the presented formulas.