Lesson 6 of 17
7. Load Balancers, Reverse Proxies and API Gateways

7.5 What are sticky sessions, and should you use them?

3 min read+10 XP

At the airport: A family checking in together wants the same agent for every bag. The queue manager remembers "that family is with counter 3" and keeps sending them there.

In the system: Sticky sessions (session affinity) make the load balancer send all of one user's requests to the same server, usually by setting a cookie (L7) or by hashing the client IP (7.3.4).

They're used when a server keeps something about the user in its own memory: an in-memory session, a half-uploaded file, a WebSocket connection (Chapter 21).

The problems:

  • Uneven load: a few heavy users stuck to one server can overload it while others idle.
  • Failures still lose state: if that server dies, the user's session dies with it.
  • Scaling in is painful: you can't remove a server without kicking off its users.

Better: make servers stateless and keep sessions in a shared store (Chapter 6, section 6.5). Use stickiness only where the connection itself must stay put, like WebSockets, and even then keep the important state elsewhere.

Memory code: "Sticky sessions hide state; they don't remove it."