Algorithms: Round Robin, Leastconn and Hash

2. Load balancing algorithms #

How does the load balancer choose the destination server?

Round robin #

This is the simplest algorithm: requests are sent to the servers sequentially. It is ideal when the servers have identical capacities.

• Pros: extremely simple, no overhead, perfectly fair on identical servers.
• Cons: inefficient if servers have different capacities or if some requests are heavier than others.

HAProxy configuration example:

backend app_servers
    balance roundrobin
    server s1 192.168.1.10:80 check
    server s2 192.168.1.11:80 check

Weighted round robin #

Each server has a weight proportional to its processing capacity. A more powerful server handles a larger share of requests.

• Pros: suited to heterogeneous server fleets, predictable behavior.
• Cons: requires manual weight configuration and does not adapt to the real instantaneous load.

HAProxy configuration example:

backend app_servers
    balance roundrobin
    server s1 192.168.1.10:80 check weight 100
    server s2 192.168.1.11:80 check weight 200

Least connections #

This algorithm sends the new request to the server with the fewest active connections. Very effective for sessions of variable duration.

• Pros: effective dynamic balancing, ideal for persistent connections (databases, WebSockets).
• Cons: slight overhead to track connections; can be misleading if requests vary in complexity.

HAProxy configuration example:

backend app_servers
    balance leastconn
    server s1 192.168.1.10:80 check
    server s2 192.168.1.11:80 check

Weighted least connections #

Combines the least connections algorithm with a weight system to favor the most robust servers with little active load.

• Pros: the most accurate for mixed infrastructures with long sessions.
• Cons: uses more computing resources on the load balancer (overhead).

HAProxy configuration example:

backend app_servers
    balance wlc
    server s1 192.168.1.10:80 check weight 100
    server s2 192.168.1.11:80 check weight 200

Least response time #

Sends requests to the server with the shortest response time and the fewest active connections. Ideal for maximum responsiveness.

• Pros: directly optimizes the user experience, avoids slowed-down servers.
• Cons: compute-intensive; risk of instability if response times change abruptly.

HAProxy configuration example:

backend app_servers
    balance rtime # Requiert HAProxy 2.x+
    server s1 192.168.1.10:80 check
    server s2 192.168.1.11:80 check

IP hash / source hash #

The user's IP address determines the destination server, guaranteeing session persistence (stickiness).

• Pros: persistence without server-side cookie management.
• Cons: possible imbalance if many users share the same IP (proxy/NAT); full redistribution if the number of servers changes.

HAProxy configuration example:

backend app_servers
    balance source
    server s1 192.168.1.10:80 check
    server s2 192.168.1.11:80 check

Random #

The load balancer picks a server at random from the pool. Simple and statistically effective on massive traffic volumes.

• Pros: zero overhead, very efficient for very large clusters.
• Cons: no guarantee of fairness on small request volumes.

HAProxy configuration example:

backend app_servers
    balance random
    server s1 192.168.1.10:80 check
    server s2 192.168.1.11:80 check

3. Tools and application examples #

Common software and cloud solutions.

Specialized software #

• HAProxy: the industry standard for high performance and reliability. Discover the HAProxy course.
• Traefik: designed for cloud native, ideal for Docker and Kubernetes. Discover the Traefik course.
• Nginx: a versatile web server with robust load balancing features.

Cloud and hardware #

• Cloud load balancers: AWS ELB, Azure Load Balancer or Google Cloud Load Balancing are very popular managed services.
• Hardware: physical appliances such as F5 BIG-IP, although less common today in favor of software and cloud.

Conclusion #

A critical element for resilience.

The move towards the service mesh #

Load balancing is no longer limited to the network edge. In microservice architectures (Kubernetes), service meshes (such as Istio or Linkerd) are used to balance load directly between the application's internal components.