Load Balancing

Algorithms, health checks, and capacity planning

Not Started

Load balancers are the unsung heroes of high availability. They distribute traffic across servers, detect failures in milliseconds, and ensure no single point of failure. The choice between Layer 4 (TCP) and Layer 7 (HTTP) balancing is a trade-off: L4 handles millions of connections with minimal overhead, while L7 enables smart routing based on content, cookies, or headers.

Algorithm selection matters: use least connections for long-lived requests, round-robin for uniform workloads, and consistent hashing for stateful services. Health checks are critical—configure aggressive timeouts (1-2 seconds) to quickly remove failed servers from rotation.

⚡ Quick Decision

Choose Layer 4 When:

• Need maximum throughput (>1M RPS)
• TCP/UDP protocols
• Minimal latency overhead

Choose Layer 7 When:

• Need content-based routing
• SSL termination required
• A/B testing & canary deploys

Algorithm Choice:

• Round Robin: Uniform workloads
• Least Connections: Long-lived requests
• IP Hash: Session affinity

💡 For implementation guides and code examples: See our comprehensive Proxies & Load Balancing Technology Deep Dive

Layer 4 vs Layer 7 Decision

Layer choice impacts throughput, latency, and features. Choose based on your primary constraint.

🏎️ Layer 4 (Transport)

Throughput: 2M+ RPS (HAProxy)

Latency: +0.1ms overhead

Memory: 4KB per connection

Best for: High-performance TCP/UDP

🌐 Layer 7 (Application)

Throughput: 200K RPS (NGINX)

Latency: +2ms overhead

Memory: 64KB per connection

Best for: HTTP routing & SSL termination

Algorithm Selection Matrix

Choose your load balancing algorithm based on traffic patterns and session requirements.

Round RobinEqual capacity servers

✓ Advantage:

Simple, fair distribution

✗ Trade-off:

Ignores server load

Weighted Round RobinDifferent capacity servers

✓ Advantage:

Accounts for server specs

✗ Trade-off:

Static weights

Least ConnectionsLong-lived connections

✓ Advantage:

Dynamic load awareness

✗ Trade-off:

Connection ≠ load

IP HashSession affinity needed

✓ Advantage:

Sticky sessions

✗ Trade-off:

Uneven distribution

Least Response TimeLatency-sensitive apps

✓ Advantage:

Optimizes for speed

✗ Trade-off:

More overhead

Health Check Strategy

Health Check Types

TCP Check (Basic)

• Latency: ~1ms

• Use for: Simple port connectivity

HTTP Check (Recommended)

• Latency: ~10ms

• Use for: Application health

Configuration Guidelines

Check interval:1-5 seconds

Timeout:1-2 seconds

Failure threshold:3 consecutive

Success threshold:2 consecutive

⚠️ Critical Health Check Rules

• Exclude health endpoints from rate limiting
• Health checks should not modify application state
• Use separate health check pools for dependencies
• Monitor health check response times

Real-World Performance

Typical throughput numbers for production load balancers.

HAProxy (L4)

High-performance TCP

2M RPS

NGINX (L7)

HTTP with SSL termination

200K RPS

AWS ALB (L7)

Managed HTTP load balancer

100K RPS

Production Deployment Checklist

🔧 Essential Setup

□Deploy load balancers in HA pairs
□Configure aggressive health check timeouts
□Set up monitoring for backend health
□Enable connection draining for deployments

⚡ Performance Tuning

□Tune TCP buffer sizes for high throughput
□Enable connection pooling to backends
□Configure keep-alive for HTTP/1.1
□Monitor CPU and memory utilization

⚠️ Avoid Single Points of Failure

Always deploy load balancers in pairs with keepalived or equivalent failover. A single load balancer failure should never take down your entire application.

No quiz questions available

Quiz ID "load-balancing" not found