What are Sticky Sessions in Load Balancing?
Learn what sticky sessions are, how session affinity works at a load balancer, and its trade-offs versus stateless servers.
Expected Interview Answer
Sticky sessions (session affinity) are a load balancer configuration that routes all requests from a given client to the same backend server for the duration of a session, typically using a cookie or the client’s connection details, instead of distributing each request independently.
Without stickiness, a load balancer spreads requests across servers using round robin or least connections, which works well when servers are stateless. If a server keeps session state in local memory — like a shopping cart or authentication session not stored in a shared store — a client must keep hitting that same server or its state appears to vanish, so the load balancer sets a cookie identifying which server to pin the client to. The trade-off is uneven load distribution (a server with many long-lived sticky clients can get overloaded while another sits idle) and reduced fault tolerance (if that server dies, all its pinned sessions lose their state). The generally preferred alternative at scale is to keep servers stateless and store session state in a shared store like Redis, so any server can handle any request and sticky sessions become unnecessary.
- Lets a server keep session state locally in memory without needing a shared store
- Simple to configure at the load balancer with a cookie-based or IP-based rule
- Improves cache locality when a server has warmed up per-client data
- Avoids the latency of round-tripping to an external session store on every request
AI Mentor Explanation
Sticky sessions are like a coaching academy always assigning the same student to the same coach for every session instead of rotating them among available coaches. That coach remembers the student’s technique quirks and history without needing to consult shared notes each time, which speeds up personalized coaching. But if that one coach gets overbooked with many students while others sit idle, or that coach is suddenly unavailable, the student loses continuity entirely. That pinned, one-server-per-client assignment with those exact trade-offs is what sticky sessions do at a load balancer.
Step-by-Step Explanation
Step 1
Client sends first request
The load balancer picks a backend server using its normal algorithm (round robin, least connections, etc.) since no affinity exists yet.
Step 2
Load balancer sets an affinity cookie
The load balancer (or the backend) sets a cookie identifying which server handled the request.
Step 3
Subsequent requests are pinned
On future requests, the load balancer reads the cookie and routes the client back to that same server.
Step 4
Handle server loss
If the pinned server goes down, the load balancer must fall back to routing that client elsewhere, and any in-memory state on the dead server is lost.
What Interviewer Expects
- Explains the mechanism: cookie or IP-based pinning of a client to one backend server
- States the reason sticky sessions are needed: server-local session state instead of a shared store
- Identifies the trade-offs: uneven load distribution and lost state on server failure
- Recommends the stateless-server-plus-shared-session-store alternative as the more scalable design
Common Mistakes
- Assuming sticky sessions eliminate the need to think about server failure
- Not mentioning the uneven-load trade-off when some clients are much longer-lived than others
- Confusing sticky sessions with simple round-robin load balancing
- Failing to suggest the stateless-plus-shared-store alternative as generally preferable at scale
Best Answer (HR Friendly)
“Sticky sessions mean a load balancer keeps sending the same user back to the same server every time, usually because that server is holding onto some session information locally. It works well for simple setups, but it can cause uneven load and problems if that particular server goes down, so many systems prefer to keep servers stateless and share session data in a common store instead.”
Code Example
loadBalancer:
algorithm: round-robin
stickySessions:
enabled: true
type: cookie
cookieName: LB_AFFINITY
ttlSeconds: 3600
healthCheck:
path: /healthz
intervalSeconds: 10
unhealthyThreshold: 3
onServerUnhealthy: reroute-affected-sessionsFollow-up Questions
- What happens to a client’s session if the server it is pinned to crashes?
- How would you migrate a system away from sticky sessions to stateless servers with shared session storage?
- How do sticky sessions interact with autoscaling, where new servers start with no pinned traffic?
- What is the difference between cookie-based affinity and IP-hash-based affinity?
MCQ Practice
1. What is the primary purpose of sticky sessions at a load balancer?
Sticky sessions pin a client to one backend server, typically via a cookie, instead of distributing each request independently.
2. What is a key downside of relying on sticky sessions?
A server with many pinned long-lived clients can become overloaded, and its clients lose state entirely if it crashes.
3. What is the generally preferred alternative to sticky sessions at scale?
Stateless servers with a shared session store let any server handle any request, removing the need for session affinity.
Flash Cards
What are sticky sessions? — Load balancer routing that pins a client to the same backend server for the session, usually via a cookie.
Why are sticky sessions used? — When a server keeps session state locally in memory instead of a shared store.
Main downside of sticky sessions? — Uneven load distribution and lost state if the pinned server fails.
Preferred alternative at scale? — Stateless servers with session state in a shared store like Redis.