Load Balancing Algorithms ⚖️ — How Traffic Is Distributed

A load balancing algorithm decides which backend server should receive an incoming request.

flowchart LR
    C["Clients"] --> LB["Load Balancer"]

    LB --> S1["Server 1"]
    LB --> S2["Server 2"]
    LB --> S3["Server 3"]

1. Round Robin

Requests are distributed sequentially across servers.

flowchart LR
    LB["Load Balancer"]

    LB -->|Request 1| S1["Server 1"]
    LB -->|Request 2| S2["Server 2"]
    LB -->|Request 3| S3["Server 3"]
    LB -->|Request 4| S1
    LB -->|Request 5| S2

Best when: servers have similar capacity and requests have roughly similar processing cost.

2. Weighted Round Robin

More powerful servers receive more traffic.

flowchart LR
    LB["Load Balancer"]

    LB -->|"Weight 5"| S1["Powerful Server"]
    LB -->|"Weight 3"| S2["Medium Server"]
    LB -->|"Weight 1"| S3["Small Server"]

Useful when backend servers have different capacities.

3. Least Connections

The request is sent to the server currently handling the fewest active connections.

flowchart LR
    LB["Load Balancer"]

    LB -->|"10 connections"| S1["Server 1"]
    LB -->|"4 connections"| S2["Server 2"]
    LB -->|"8 connections"| S3["Server 3"]

    S2 -->|"New Request"| R["Request"]

Useful when requests have different processing times.

4. Weighted Least Connections

Combines server capacity with the number of active connections.

A powerful server can handle more connections than a smaller server.

5. IP Hash

The client's IP address is hashed to determine the backend server.

flowchart LR
    C["Client IP"] --> H["Hash"]
    H --> S["Backend Server"]

The same client IP will generally reach the same backend server while the server mapping remains stable.

It can be useful when applications require some form of session affinity.

6. Consistent Hashing

Consistent hashing distributes keys across servers while minimizing the number of keys that move when servers are added or removed.

flowchart LR
    K["User / Key"] --> H["Hash"]
    H --> N["Hash Ring"]
    N --> S["Selected Server"]

It is commonly discussed in distributed systems, caching and partitioning.

7. Random

A server is selected randomly.

It is simple, but it does not consider server load or capacity.

8. Least Response Time

The load balancer considers server response time and sometimes the number of active connections to choose a suitable server.

This can be useful when backend servers have different performance characteristics.

9. Algorithm Comparison

10. What About Session Affinity?

If a user's session is stored only on one server, requests may need to return to that server.

flowchart LR
    C["User"] --> LB["Load Balancer"]

    LB -->|"Same User"| S1["Server 1"]
    LB --> S2["Server 2"]

However, in a scalable system, it is usually better to keep application servers stateless and store shared session state externally.

flowchart LR
    C["Client"] --> LB["Load Balancer"]

    LB --> S1["API 1"]
    LB --> S2["API 2"]
    LB --> S3["API 3"]

    S1 --> R["Shared Redis / Session Store"]
    S2 --> R
    S3 --> R

Important Interview Questions

• What is Round Robin?
• Round Robin vs Weighted Round Robin?
• When would you use Least Connections?
• What is IP Hash?
• What is consistent hashing?
• How would you handle servers with different capacities?
• Why can sticky sessions be problematic?
• How do you distribute traffic when servers are stateless?
• Which algorithm would you choose when request processing times vary?

Key Takeaways

• Round Robin → simple sequential distribution.
• Weighted Round Robin → considers server capacity.
• Least Connections → considers active connections.
• IP Hash → provides client-to-server affinity.
• Consistent Hashing → minimizes redistribution when nodes change.
• Stateless services usually make load balancing easier.

Conclusion

In an interview, don't simply say "use Round Robin." First consider server capacity, request duration, session requirements, and whether the application is stateless.