0. Load Balancing Algorithms

---

1. Round Robin

Overview

Distributes requests sequentially across all available backend servers.

Flow

flowchart LR

    C((Client))

    P1[Pod A]
    P2[Pod B]
    P3[Pod C]

    C -->|Request 1| P1
    C -->|Request 2| P2
    C -->|Request 3| P3
    C -->|Request 4| P1
    C -->|Request 5| P2
    C -->|Request 6| P3

Advantages

• Simple implementation
• Very low overhead
• Fair when all servers have similar capacity

Disadvantages

• Ignores server load
• Slow or overloaded servers continue receiving requests

Best Use Cases

• Stateless applications
• Uniform workloads
• Equal-capacity backend servers

---

2. Least Connections

Overview

Routes incoming requests to the backend with the fewest active connections.

Current State

flowchart TB

    LB[Load Balancer]

    A["Pod A<br/>12 Connections"]
    B["Pod B<br/>4 Connections"]
    C["Pod C<br/>7 Connections"]

    LB --> A
    LB -->|Next Request| B
    LB --> C

Decision Process

flowchart LR

    R[New Request]

    A["Pod A<br/>12"]
    B["Pod B<br/>4"]
    C["Pod C<br/>7"]

    R --> B

The load balancer selects Pod B because it currently has the fewest active connections.

Advantages

• Adapts to real-time load
• Better resource utilization
• Ideal for requests with varying durations

Disadvantages

• Slightly more computational overhead
• Requires tracking active connections
• Not supported by every load balancer

Best Use Cases

• REST APIs
• File uploads
• Streaming services
• Long-running requests

---

3. IP Hash

Overview

Uses the client’s IP address to consistently route requests to the same backend.

Routing Logic

flowchart LR

    C1["192.168.1.10"]
    C2["192.168.1.20"]
    C3["10.0.0.15"]

    H[Hash Function]

    P1[Pod A]
    P2[Pod B]
    P3[Pod C]

    C1 --> H
    C2 --> H
    C3 --> H

    H --> P1
    H --> P2
    H --> P3

Sticky Session Example

sequenceDiagram

    participant Client
    participant LB as Load Balancer
    participant PodA

    Client->>LB: Request 1 (IP = X)
    LB->>PodA: Hash(IP X)

    Client->>LB: Request 2 (IP = X)
    LB->>PodA: Hash(IP X)

    Client->>LB: Request 3 (IP = X)
    LB->>PodA: Hash(IP X)

Every request from the same client IP is routed to the same backend while that backend remains available.

Advantages

• Session persistence
• Better cache locality
• No additional session storage required

Disadvantages

• Uneven traffic distribution
• Clients behind NAT may overload a single backend
• Backend failures may move users to another server

Best Use Cases

• Chat applications
• Multiplayer games
• Legacy applications with server-side sessions
• Applications using local caches

---

Visual Comparison

flowchart TB

    subgraph Round Robin
        RR1[Request 1] --> A1[Pod A]
        RR2[Request 2] --> B1[Pod B]
        RR3[Request 3] --> C1[Pod C]
    end

    subgraph Least Connections
        LC[Next Request] --> B2["Least Busy Pod"]
    end

    subgraph IP Hash
        IP[Client IP]
        HASH[Hash]
        HASH --> SAME[Same Pod]
        IP --> HASH
    end

---

Comparison Table

Feature	Round Robin	Least Connections	IP Hash
Load Awareness	❌ No	✅ Yes	❌ No
Sticky Sessions	❌ No	❌ No	✅ Yes
Complexity	Low	Medium	Medium
Best For	Stateless Apps	Uneven Workloads	Stateful Applications
Performance	Good	Better under variable load	Depends on client distribution

---

When to Use Which?

flowchart TD

    Start[Choose Load Balancing Algorithm]

    Start --> S{Need Sticky Sessions?}

    S -->|Yes| IPHash[IP Hash]

    S -->|No| L{Request Duration Varies?}

    L -->|Yes| LC[Least Connections]

    L -->|No| RR[Round Robin]

---

Key Takeaways

• Round Robin distributes requests equally without considering server load.
• Least Connections selects the least busy backend based on active connections.
• IP Hash keeps the same client connected to the same backend, enabling sticky sessions.

---