Load Balancing Algorithms

Overview

UltraBalancer supports multiple load balancing algorithms, each optimized for different use cases. Choosing the right algorithm is crucial for optimal performance and reliability.

Available Algorithms

Round Robin

Equal distribution in sequential order

Least Connections

Routes to backend with fewest active connections

IP Hash

Consistent hashing based on client IP

Weighted Round Robin

Distribution based on backend weights

Random

Random backend selection

Round Robin

How It Works

Distributes requests sequentially across all healthy backends in a circular fashion.

Request 1 → Backend A
Request 2 → Backend B
Request 3 → Backend C
Request 4 → Backend A
Request 5 → Backend B
...

Best For

Homogeneous backends with similar capacity
Stateless applications where any backend can handle any request
Simple deployments where you want equal distribution

Usage

CLI

ultrabalancer start round-robin \
  backend1:8080 \
  backend2:8080 \
  backend3:8080

Config File

algorithm: "round-robin"
backends:
  - host: "backend1"
    port: 8080
  - host: "backend2"
    port: 8080
  - host: "backend3"
    port: 8080

Characteristics

Pros

Simple and predictable
Even distribution over time
Low computational overhead
No state required

Cons

Doesn’t consider backend load
May unevenly distribute long-running requests
Not suitable for heterogeneous backends

Least Connections

How It Works

Routes each request to the backend with the fewest active connections, ensuring optimal load distribution.

Backend A: 5 connections  ← Request routed here
Backend B: 10 connections
Backend C: 8 connections

Best For

Long-lived connections (WebSockets, streaming)
Variable request durations
Real-time load balancing
Heterogeneous workloads

Usage

CLI

ultrabalancer start least-connections \
  backend1:8080 \
  backend2:8080 \
  backend3:8080

Config File

algorithm: "least-connections"
backends:
  - host: "backend1"
    port: 8080
  - host: "backend2"
    port: 8080
  - host: "backend3"
    port: 8080

Characteristics

Pros

Dynamic load distribution
Handles variable request times well
Optimal for long-lived connections
Prevents backend overload

Cons

Slight computational overhead
Requires connection tracking
May cause “thundering herd” on restart

IP Hash

How It Works

Uses consistent hashing on the client’s IP address to always route the same client to the same backend.

Client 192.168.1.100 → hash → Backend B
Client 192.168.1.101 → hash → Backend A
Client 192.168.1.102 → hash → Backend C

# Same client always goes to same backend
Client 192.168.1.100 → hash → Backend B ✓

Best For

Session persistence without cookies
Stateful applications requiring sticky sessions
Cache locality optimization
WebSocket applications

Usage

CLI

ultrabalancer start ip-hash \
  backend1:8080 \
  backend2:8080 \
  backend3:8080

Config File

algorithm: "ip-hash"
backends:
  - host: "backend1"
    port: 8080
  - host: "backend2"
    port: 8080
  - host: "backend3"
    port: 8080

Characteristics

Pros

Session persistence without cookies
Excellent cache hit rates
Predictable routing
No server-side session storage needed

Cons

Uneven distribution if client IPs skewed
NAT/proxy may group many clients
Backend changes disrupt sessions
Not suitable for APIs behind CDN

NAT Considerations: Clients behind NAT will share the same IP and always route to the same backend. This can cause imbalance in corporate networks or mobile carriers.

Weighted Round Robin

How It Works

Distributes requests based on assigned weights, allowing prioritization of more powerful backends.

Backend A (weight: 100) → Gets ~50% of traffic
Backend B (weight: 100) → Gets ~50% of traffic
Backend C (weight: 50)  → Gets ~25% of traffic

Best For

Heterogeneous backends with different capacities
Phased rollouts (canary deployments)
Multi-zone deployments (prefer same-zone backends)
Hardware variations (different CPU/memory)

Usage

CLI

ultrabalancer start weighted \
  powerful-server:8080 \
  medium-server:8080 \
  backup-server:8080 \
  -w 100

Config File

algorithm: "weighted"
backends:
  - host: "powerful-server"
    port: 8080
    weight: 200  # Gets 2x traffic
  - host: "medium-server"
    port: 8080
    weight: 100  # Gets 1x traffic
  - host: "backup-server"
    port: 8080
    weight: 50   # Gets 0.5x traffic

Characteristics

Pros

Handles heterogeneous backends
Perfect for capacity planning
Enables canary deployments
Flexible traffic control

Cons

Requires weight tuning
More complex configuration
Static weights don’t adapt to load

Weight Examples

# Route 90% to stable, 10% to canary
backends:
  - host: "stable-v1"
    port: 8080
    weight: 90
  - host: "canary-v2"
    port: 8080
    weight: 10

Random

How It Works

Selects a backend randomly for each request.

Best For

Testing and development
Stateless microservices
Simple deployments
Load testing scenarios

Usage

CLI

ultrabalancer start random \
  backend1:8080 \
  backend2:8080 \
  backend3:8080

Config File

algorithm: "random"
backends:
  - host: "backend1"
    port: 8080
  - host: "backend2"
    port: 8080
  - host: "backend3"
    port: 8080

Characteristics

Pros

Simple implementation
No state required
Even distribution over time
Unpredictable (good for testing)

Cons

Short-term imbalance possible
Not deterministic
Rarely optimal for production

Algorithm Comparison

Algorithm	Session Persistence	Load Awareness	Complexity	Best Use Case
Round Robin	❌	❌	Low	Homogeneous backends
Least Connections	❌	✅	Medium	Variable workloads
IP Hash	✅	❌	Medium	Stateful apps
Weighted RR	❌	⚠️ Static	Medium	Heterogeneous backends
Random	❌	❌	Low	Testing

Choosing the Right Algorithm

Assess Your Requirements

Do you need session persistence? → IP Hash
Do backends have different capacities? → Weighted Round Robin
Do requests have variable durations? → Least Connections
Simple stateless app with equal backends? → Round Robin

Consider Your Traffic

WebSocket/long-lived connections? → Least Connections
High request rate with short responses? → Round Robin
Users need consistent backend? → IP Hash

Test and Monitor

Start with Round Robin and monitor:

Backend utilization
Response times
Error rates
Connection distribution

Switch algorithms if metrics suggest imbalance.

Next Steps

Health Checks

Learn about automatic failover

Configuration

Master configuration options

Monitoring

Track algorithm performance

Production Guide

Deploy with confidence

Getting Started

Concepts

Configuration

Deployment

Testing

API

Advanced

​Overview

​Available Algorithms

Round Robin

Least Connections

IP Hash

Weighted Round Robin

Random

​Round Robin

​How It Works

​Best For

​Usage

​Characteristics

​Least Connections

​How It Works

​Best For

​Usage

​Characteristics

​IP Hash

​How It Works

​Best For

​Usage

​Characteristics

​Weighted Round Robin

​How It Works

​Best For

​Usage

​Characteristics

​Weight Examples

​Random

​How It Works

​Best For

​Usage

​Characteristics

​Algorithm Comparison

​Choosing the Right Algorithm

​Next Steps

Health Checks

Configuration

Monitoring

Production Guide

Overview

Available Algorithms

Round Robin

How It Works

Best For

Usage

Characteristics

Least Connections

How It Works

Best For

Usage

Characteristics

IP Hash

How It Works

Best For

Usage

Characteristics

Weighted Round Robin

How It Works

Best For

Usage

Characteristics

Weight Examples

Random

How It Works

Best For

Usage

Characteristics

Algorithm Comparison

Choosing the Right Algorithm

Next Steps