What is load balancing and how do I configure Nginx as a load balancer?

Load balancing distributes incoming network traffic across multiple backend servers, ensuring no single server handles all requests, thereby improving response time, reliability, and capacity. When one backend fails, load balancers automatically route traffic to healthy servers.

DETAILED EXPLANATION:
Load balancing algorithms:
- Round Robin: Requests distributed sequentially (default Nginx)
- Least Connections: New request goes to server with fewest active connections
- IP Hash: Same client IP always goes to same server (session persistence)
- Weighted: Servers with more capacity receive proportionally more requests

HAProxy vs Nginx vs AWS ELB vs CloudFlare:
- Nginx: Lightweight, HTTP/HTTPS, good for web traffic, built-in health checks
- HAProxy: TCP + HTTP, more granular health checks, better for non-HTTP protocols
- AWS ELB/ALB: Managed service, auto-scales, integrates with AWS ecosystem
- Cloudflare: CDN + load balancer, global, adds latency protection

WHEN TO USE:
- Application outgrows single server capacity
- Requiring zero-downtime deployments (drain one server, update, add back)
- Geographic distribution for latency reduction
- High availability (N+1 redundancy)

STEP-BY-STEP — Nginx Load Balancer configuration:

# /etc/nginx/nginx.conf

http {
# Define upstream servers (backend pool)
upstream app_servers {
least_conn; # Use least connections algorithm

server 10.0.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
server 10.0.1.12:8080 weight=1 max_fails=3 fail_timeout=30s; # Standby

keepalive 32; # Connection pool
}

server {
listen 80;
server_name yourdomain.com;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
server_name yourdomain.com;

ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

location / {
proxy_pass http://app_servers;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

# Health check
proxy_next_upstream error timeout invalid_header http_500 http_503;
proxy_connect_timeout 2s;
proxy_read_timeout 60s;
}

# Health check endpoint
location /nginx-health {
access_log off;
return 200 "healthy";
}
}
}

# Test and reload
nginx -t && nginx -s reload

# Monitor upstream status
curl http://localhost/nginx-health

FLOW:
[ Users ] → [ Nginx Load Balancer (SSL termination) ] → Round-robin/Least-conn → [ App Server 1 ] / [ App Server 2 ] / [ App Server 3 ]

KEY POINTS:
- Use sticky sessions (ip_hash) for stateful apps that don't use shared Redis sessions
- Health checks remove failed backends automatically
- SSL termination at load balancer reduces CPU load on backend servers
- Connect Quest dedicated servers ideal for load balancer + application tier setup

COMMON MISTAKES:
- Load balancing without shared session storage (users lose sessions on different servers)
- Not setting X-Real-IP header (app sees load balancer IP not user IP)
- Forgetting to add backend servers to same private VLAN

QUICK FIX:
Backend server removed from rotation → check: nginx error_log for upstream connect errors, verify backend service is running: systemctl status appname

DIFFICULTY: Advanced
RELATED: VPS Hosting, Nginx, Cloud Hosting, High Availability