Sticky sessions and session storage
Two ways to keep a user's session working across servers, and when stickiness backfires.
Say you cannot make the app fully stateless yet; sessions live in server memory. A quick workaround is sticky sessions (session affinity): the load balancer remembers which server handled a user, using a cookie or a hash of the client, and keeps sending that user there. It fixes the logged-out bug with no code change, which is why it is common.
The trouble is what stickiness costs. Load stops being balanced by request cost because users are pinned. A few heavy users, or a single large office behind one IP address, can overload one server while others idle. And when the pinned server dies or is replaced, every session on it is lost, so users are logged out and carts vanish. Deploys and autoscaling-in also destroy sessions.
Hashing pins a busy client to one server
Client a sends most of the traffic. Run with ip-hash on 3 servers and see how unevenly requests fall. Then switch to round robin to see the spread (and think about what you would lose).
- 2 cost, client a
- 2 cost, client a
- 2 cost, client a
- 2 cost, client a
- 2 cost, client a
- 2 cost, client a
- 2 cost, client a
- 2 cost, client b
- 2 cost, client c
- 2 cost, client a
- 2 cost, client b
In this run one server receives 8 of the 11 requests and another gets just 1, because client a always hashes to the same server. Round robin would give 4 and 3 and so on, but it would break any session held in a server's memory. That is the tension: affinity helps correctness of local state but hurts balance and resilience.
Better: put sessions in a shared store
Step 1 of 3
Server-side session in a shared store
The cookie holds only a random session id. Any server looks it up in a fast shared store (an in-memory key-value store, replicated). Sessions can be revoked instantly.
Your turn
A company office of 4,000 people shares one public IP and your balancer uses ip-hash with 4 servers. What goes wrong and what do you change?
Stuck? All 4,000 users look like one client.
What to remember
Sticky sessions pin a user to one server, fixing local-state bugs without code changes.
They cause uneven load and lose sessions when a server dies or is replaced.
Prefer a shared session store or signed tokens so any server works.
If you keep stickiness, treat it as a hint, not a requirement for correctness.