How do load balancers handle sticky sessions for WebSockets?
Learn why WebSockets need sticky sessions, how load balancers enforce affinity via cookies or IP hash, and why a Redis backplane is still needed to scale.
Expected Interview Answer
A load balancer uses sticky sessions (session affinity) to always route a given client's requests to the same backend server, which WebSockets need because a connection is long-lived and stateful. Affinity is typically enforced with a cookie or by hashing the client's IP so the upgraded connection and any fallback polling requests stay on one server.
WebSockets begin as an HTTP request that is upgraded to a persistent connection; that connection lives entirely on one server, so requests must not be scattered across the pool. Layer 4 balancers hash source IP/port, while Layer 7 balancers issue an affinity cookie. Sticky sessions alone do not synchronize state between servers — for cross-server broadcasts you still add a pub/sub backplane like the Redis adapter, so affinity handles routing and the backplane handles shared messaging.
- Keeps a long-lived WebSocket pinned to one server
- Prevents broken upgrades from scattered routing
- Supports Socket.IO HTTP long-polling fallback
- Works at Layer 4 (IP hash) or Layer 7 (cookie)
- Pairs with a backplane for cross-server messaging
AI Mentor Explanation
A batter who begins an innings must keep facing deliveries from the same end with the same umpire tracking the count; you cannot swap umpires mid-over or the tally is lost. Sticky sessions do this for WebSockets: once a client's connection lands on a server, the load balancer keeps sending that client back to the same server, so the ongoing innings of a stateful connection is never handed to a stranger who has no record of it.
Step-by-Step Explanation
Step 1
Client opens a connection
An HTTP request hits the load balancer and is upgraded to a persistent WebSocket living on one backend server.
Step 2
Balancer assigns affinity
Layer 7 sets an affinity cookie; Layer 4 hashes source IP/port to pick and remember a backend.
Step 3
Subsequent requests stick
Every later request from that client — including polling fallback — is routed back to the same server.
Step 4
Preserve the upgrade
Ensure the balancer forwards Upgrade/Connection headers so the WebSocket handshake completes and stays open.
Step 5
Add a backplane for scale
Use a Redis/NATS adapter so broadcasts reach clients pinned to other servers, since affinity alone doesn't share state.
What Interviewer Expects
- WebSockets are long-lived and stateful on one server
- Sticky sessions = session affinity via cookie or IP hash
- Difference between Layer 4 and Layer 7 affinity
- Forwarding Upgrade/Connection headers through the proxy
- Affinity routes but a backplane is still needed for broadcasts
Common Mistakes
- Thinking sticky sessions synchronize state between servers
- Forgetting to forward Upgrade and Connection headers
- Assuming round-robin works for persistent connections
- Ignoring the polling fallback that also needs affinity
- Relying on IP hash when many clients share one NAT IP
Best Answer (HR Friendly)
“Because a WebSocket stays connected to one server, the load balancer must keep sending that user back to the same server instead of spreading requests around. This is called a sticky session, usually done with a cookie or by matching the user's IP, so the ongoing connection never breaks.”
Code Example
upstream ws_backend {
# ip_hash pins each client IP to one backend (Layer 4 affinity)
ip_hash;
server app1:3000;
server app2:3000;
}
server {
location /socket.io/ {
proxy_pass http://ws_backend;
# Required to keep the WebSocket upgrade alive
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}Follow-up Questions
- Why isn't round-robin enough for WebSocket connections?
- What is the difference between Layer 4 and Layer 7 affinity?
- Do sticky sessions replace the need for a Redis adapter?
- What breaks if you forget the Upgrade header in the proxy?
- How does IP hash behave when many users share a NAT gateway?
MCQ Practice
1. Why do WebSockets require sticky sessions behind a load balancer?
A WebSocket lives on a single backend, so requests must consistently return to that server; scattering them would break the persistent connection.
2. Which mechanism commonly enforces Layer 7 session affinity?
Layer 7 balancers set an affinity cookie to route a client back to the same server; Layer 4 typically hashes source IP/port instead.
3. Do sticky sessions remove the need for a Redis/pub-sub backplane?
Affinity keeps a client on one server but doesn't sync state; broadcasting to clients on other servers still needs a pub/sub backplane.
Flash Cards
What is a sticky session? — Session affinity that routes a client's requests back to the same backend server for the connection's life.
Why do WebSockets need it? — The connection is long-lived and stateful on one server, so requests must not scatter across the pool.
Layer 4 vs Layer 7 affinity? — Layer 4 hashes source IP/port; Layer 7 issues an affinity cookie.
Do sticky sessions share state? — No — they only route. Cross-server broadcasts still need a pub/sub backplane like Redis.