The Problem That Won't Go Away
You've deployed three servers behind a . Everything is beautiful. Then your product manager comes to you and says: "Users are getting randomly logged out. Their shopping carts disappear. The form they spent 10 minutes filling out just reset itself."
You check the servers. They're all healthy. The load balancer is working. The code is correct. So what's happening?
Here's the issue: when a user logs in and their session is stored in Server A's memory, their next request might get routed to Server B. Server B has no idea who this user is. No session, no cart, no form state. To Server B, this is a brand new anonymous visitor.
This is the classic stateful server problem, and sticky sessions are the most common band-aid. A sticky session ensures that once a user is routed to a specific server, all subsequent requests from that user go to the same server for the duration of their session.
It sounds like a hack, and honestly, it kind of is. But it's a hack that powers a surprising amount of the internet, and understanding when to use it (and when to avoid it) is important.
Sticky Session Cookie Flow
The important detail in that flow is who issues the cookie.
That is why stickiness can be switched on with one configuration flag and no code change at all.
It is also the reason everything that goes wrong later goes wrong: the thing making the routing decision has no idea what the session is or how long it should last.
The client kept working and is now on a machine that has never seen it before. If the session lived in 8822's memory, it is gone and the user is logged out.
Nothing failed and nothing was misconfigured. That is what stickiness does when the pin disappears.
Nothing failed here either. The balancer did exactly what it was configured to do, and the state was in the wrong place.
There are only two ways out: send the user back to the same machine, or stop keeping the state on one machine.