What are sticky sessions and why do many teams avoid them?
Sticky sessions make the load balancer send a user to the same server every time, usually via a cookie. They avoid shared session storage but cause uneven load and lose the session if that server dies.
Explain it simply
If a user's login session lives in one server's memory, the next request must reach that same server or the user appears logged out. A sticky session (session affinity) forces that: the balancer remembers which server served you, often using a cookie, and keeps sending you back.
Why teams avoid it:
- Uneven load: a few heavy users pile onto one server while others idle.
- Failure hurts users: if that server crashes or is replaced during a deploy, its sessions vanish and users are logged out.
- Scaling down is awkward: you cannot remove a server without disrupting its users.
The usual fix is making servers stateless: keep sessions in a shared Redis or put them in a signed token such as a JWT, so any server can serve any user.
Stickiness is still acceptable for short-lived needs, like a WebSocket connection that must stay on one machine, or an upload spread over several requests.
Example
Two servers; user Asha is pinned to S1.
Request 1 -> S1 (session created in S1 memory)
Request 2 -> S1 (cookie says S1)
S1 crashes during a deploy
Request 3 -> S2 (no session found) -> "Please log in again"With Redis-held sessions, request 3 on S2 would have worked.
What to say in the interview
"Sticky sessions pin a client to one server so local session memory keeps working. The cost is imbalanced load and lost sessions when that server dies. I prefer stateless servers with sessions in Redis or signed tokens, and use stickiness only where a connection genuinely needs it."