Sticky sessions and load balancing for WebSocket servers
sticky session definition, IP hash load balancing, cookie-based affinity, Nginx upstream hash, AWS ALB stickiness, session affinity limitations, failover behavior
What Sticky Sessions Actually Do
Sticky sessions ensure a client always reconnects to the same backend server. The load balancer routes based on IP or a cookie. Configure Nginx:
upstream websocket_backend {
ip_hash; # route same IP to same server
server 10.0.0.1:3000;
server 10.0.0.2:3000;
server 10.0.0.3:3000;
}
server {
listen 80;
location /ws {
proxy_pass http://websocket_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_read_timeout 3600s; # keep alive for 1 hour
}
}Limitations of Sticky Sessions Alone
If a server crashes, all its clients lose their sticky affinity and reconnect to other servers - losing in-memory state. Sticky sessions are not a substitute for a shared state layer (Redis). Use both: sticky sessions as the primary routing strategy to minimize cross-server traffic, Redis for broadcast and state recovery after failover. On AWS, use Application Load Balancer with duration-based stickiness and set the timeout longer than your WebSocket idle timeout.