When state lives on the server
If a backend keeps per user session data in memory, sending that user's next request to a different backend loses the state. Sticky sessions, or session affinity, pin a client to the same backend for the life of the session.
How stickiness is established
- Cookie based: the balancer inserts a cookie naming the chosen backend and reads it on later requests. This is an L7 feature.
- Source IP based: the balancer hashes the client IP to a backend. Works at L4 but breaks when many users share one IP behind a proxy.
The tradeoffs
Stickiness is convenient but has real costs.
- It can unbalance load, since a heavy user stays pinned to one node.
- It complicates draining and failover: if the pinned backend dies, the session is lost.
- It hides scaling problems that stateless designs avoid.
The better default
The cleaner approach is to externalize session state into a shared store such as a cache or database, making backends stateless. Then any balancing policy works and a dead backend costs nothing. Sticky sessions are a pragmatic fix when you cannot easily make the backend stateless.
Key idea
Sticky sessions pin a client to one backend via cookie or IP hash so in memory session state stays reachable, but externalizing state to a shared store is the more scalable design.