Skip to content

Load_balancing


┌─────────────────────────────────────────────────────────────────────────┐
│ ALGORITHM COMPARISON │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Round Robin: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Sequential distribution to each server in rotation │ │
│ │ • Good for servers with similar capacity │ │
│ │ • Simple, no state needed │ │
│ │ • Default in most load balancers │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Least Connections: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Routes to server with fewest active connections │ │
│ │ • Better for varying workloads │ │
│ │ • More intelligent than round robin │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ IP Hash: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Same client IP always goes to same server │ │
│ │ • Enables session persistence │ │
│ │ • Good for stateful applications │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Weighted: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Assign weight to each server │ │
│ │ • More requests to powerful servers │ │
│ │ • Useful for heterogeneous server pools │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Least Time: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Considers response time (weighted) │ │
│ │ • Routes to fastest responding servers │ │
│ │ • Best for variable latency environments │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Random: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Random server selection │ │
│ │ • Good when used with multiple load balancers │ │
│ │ • Prevents thundering herd │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘

/etc/haproxy/haproxy.cfg
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
maxconn 4000
defaults
log global
mode http
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend http_front
bind *:80
bind *:443 ssl crt /etc/ssl/certs/server.pem
# Redirect HTTP to HTTPS
http-request redirect scheme https unless { ssl_fc }
default_backend web_servers
backend web_servers
mode http
balance roundrobin
option httpchk GET /health
server web1 10.0.0.1:80 check inter 2000 rise 2 fall 3
server web2 10.0.0.2:80 check inter 2000 rise 2 fall 3
server web3 10.0.0.3:80 check inter 2000 rise 2 fall 3 backup
# Path-based routing
frontend http_front
bind *:80
acl is_api path_beg /api
acl is_admin path_beg /admin
acl is_static path_beg /static /images /js
use_backend api_servers if is_api
use_backend admin_servers if is_admin
use_backend static_servers if is_static
default_backend web_servers
# Header-based routing
frontend http_front
bind *:80
acl is_mobile hdr_val(User-Agent) -i mobile
acl is_api_header hdr(X-API-Key) -m found
use_backend mobile_servers if is_mobile
use_backend api_servers if is_api_header
default_backend web_servers
frontend https_front
bind *:443 ssl crt /etc/ssl/certs/server.pem
crt /etc/ssl/certs/additional.pem
# SSL options
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11
ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384
default_backend web_servers

┌─────────────────────────────────────────────────────────────────────────┐
│ HEALTH CHECK TYPES │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ TCP Connect (Basic): │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Opens TCP connection to port │ │
│ │ • Success if connection established │ │
│ │ • server web1 10.0.0.1:80 check │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ HTTP Check: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Sends HTTP request │ │
│ │ • Checks response code (2xx, 3xx = healthy) │ │
│ │ • Can check response body │ │
│ │ • option httpchk │ │
│ │ • option httpchk GET /health │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ HTTPS Check: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • Same as HTTP but over SSL │ │
│ │ • Can verify certificate │ │
│ │ • option httpchk GET /health ssl verify none │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Check Parameters: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • inter 2000: Check every 2 seconds │ │
│ │ • rise 2: 2 successful checks = healthy │ │
│ │ • fall 3: 3 failed checks = unhealthy │ │
│ │ • slowstart 30s: Gradual traffic increase │ │
│ │ • port 8080: Check different port than backend │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
# Custom HTTP check with expected response
backend api_servers
option httpchk
http-check expect status 200
http-check expect string "OK"
server api1 10.0.0.1:8000 check inter 3000 fall 3 rise 2
server api2 10.0.0.2:8000 check inter 3000 fall 3 rise 2
# Check on different port
backend web_servers
option httpchk
http-check send uri /healthcheck port 8080
server web1 10.0.0.1:80 check inter 2000
server web2 10.0.0.2:80 check inter 2000
# Agent-based health check
backend app_servers
option external-check
external-check path "/usr/bin:/bin"
external-check command /usr/local/bin/check_app.sh
server app1 10.0.0.1:8080 check

# Source IP persistence
backend web_servers
balance source
hash-type consistent
server web1 10.0.0.1:80 check
server web2 10.0.0.2:80 check
# Cookie-based persistence
backend api_servers
balance roundrobin
cookie SERVERID insert indirect nocache
server api1 10.0.0.1:80 check cookie api1
server api2 10.0.0.2:80 check cookie api2

┌─────────────────────────────────────────────────────────────────────────┐
│ LOAD BALANCING INTERVIEW QUESTIONS │
├─────────────────────────────────────────────────────────────────────────┤
Q1: What is load balancing? │
A1: Distributing traffic across multiple servers to improve performance, │
reliability, and scalability │
─────────────────────────────────────────────────────────────────────────┤
Q2: What is the difference between L4 and L7 load balancing? │
A2: L4 (Transport layer): TCP/UDP, no content awareness │
L7 (Application layer): HTTP/HTTPS, can inspect content, routes │
based on URL, headers, cookies │
─────────────────────────────────────────────────────────────────────────┤
Q3: What is sticky sessions and why would you use them? │
A3: Same client always routed to same server │
- Session state stored on server │
- Enables stateful applications │
- Can use IP hash or cookies │
─────────────────────────────────────────────────────────────────────────┤
Q4: What health check types are available? │
A4: TCP connect (basic), HTTP (GET request), HTTPS (SSL), │
Custom (agent-based), UDP (for non-HTTP) │
─────────────────────────────────────────────────────────────────────────┤
Q5: What is the difference between round robin and least connections? │
A5: Round robin: Sequential distribution │
Least connections: Routes to server with fewest active connections│
─────────────────────────────────────────────────────────────────────────┤
Q6: How do you handle SSL termination? │
A6: Load balancer decrypts SSL, forwards plain HTTP to backend │
- Reduces backend server CPU load │
- Centralized certificate management │
- HAProxy: bind *:443 ssl crt <cert> │
─────────────────────────────────────────────────────────────────────────┤
Q7: What is a failover in load balancing? │
A7: Automatic switch to backup server when primary fails │
- Health checks detect failure │
- Backup servers take over │
- "backup" keyword in HAProxy │
─────────────────────────────────────────────────────────────────────────┤
Q8: How do you prevent a single point of failure? │
A8: Multiple load balancers (active-active or active-passive) │
- Multiple backend servers │
- Health checks for automatic removal │
- Redundant network paths │
└─────────────────────────────────────────────────────────────────────────┘

Terminal window
# HAProxy
balance roundrobin|leastconn|source|uri
option httpchk
check inter 2000 rise 2 fall 3
# Algorithms
roundrobin # Sequential
leastconn # Fewest connections
source # IP hash
uri # URL hash

  • Algorithms: Round robin, least connections, IP hash, weighted
  • HAProxy: Popular L4/L7 load balancer
  • Health checks: TCP, HTTP, HTTPS, custom
  • Persistence: Source IP, cookies

Chapter 70: Application Servers


Last Updated: February 2026