What is Session Persistence?
Learn what session persistence (sticky sessions) is, how cookie and IP-based persistence work, and when to avoid it.
Expected Interview Answer
Session persistence (also called sticky sessions) is a load balancer feature that routes all requests from a given client to the same backend server for the duration of their session, typically implemented via a cookie, source IP hashing, or a TLS session ID, so that server-held state like an in-memory shopping cart or login session is not lost between requests.
Without persistence, a load balancer might send a client’s first request to server A and their next request to server B, which breaks any application that stores session state locally on the server rather than in a shared store. Cookie-based persistence is the most common and reliable approach: the load balancer inserts or reads a cookie identifying which backend previously served that client, and routes subsequent requests there as long as that server stays healthy. IP-based persistence hashes the client’s source IP to consistently pick a backend, but it breaks down for clients behind a shared NAT gateway (many users appear as one IP) or when a client’s IP changes (mobile networks). The better long-term architecture is often to avoid the need for persistence altogether by externalizing session state to a shared store like Redis, so any backend can serve any request — persistence is a pragmatic workaround, not a substitute for stateless service design.
- Preserves server-held session state without a shared session store
- Simple to enable at the load balancer with no application changes
- Cookie-based persistence works reliably even behind shared NAT
- Can be combined with health checks to fail a client over gracefully
AI Mentor Explanation
Session persistence is like a coach making sure a batter who started their session with a specific bowling machine keeps using that exact machine for the whole session, instead of being shuffled between machines each time they step up — because the machine has been calibrated to that batter’s stance. A wristband tagging the batter to their assigned machine mirrors a cookie tagging a client to a specific backend server. If that machine breaks down, the batter is reassigned to a new one, just as a load balancer fails a client over when their sticky server becomes unhealthy.
Step-by-Step Explanation
Step 1
First request
A client’s first request is routed to a backend server by the normal load balancing algorithm.
Step 2
Persistence marker set
The load balancer sets a cookie (or notes the client IP/TLS session) identifying that chosen backend.
Step 3
Subsequent requests
Later requests carrying that marker are routed to the same backend as long as it remains healthy.
Step 4
Failover
If the sticky backend becomes unhealthy, the client is reassigned to a new backend and a new persistence marker is set.
What Interviewer Expects
- Correct definition: routing a client consistently to the same backend
- Names at least cookie-based and IP-based persistence mechanisms
- Explains why it matters for servers holding local session state
- Knows the tradeoff versus externalizing session state to a shared store
Common Mistakes
- Confusing session persistence with session/cookie-based authentication
- Assuming IP-based persistence works reliably behind shared NAT
- Treating persistence as a permanent architectural solution instead of a workaround
- Forgetting persistence must interact correctly with health checks/failover
Best Answer (HR Friendly)
“Session persistence, or sticky sessions, means a load balancer keeps sending the same user’s requests to the same server for the length of their session — usually tracked with a cookie. It matters because if that server has stored something specific to the user, like their shopping cart in memory, bouncing them to a different server could lose that information.”
Code Example
upstream backend_pool {
server 10.0.0.1:8080;
server 10.0.0.2:8080;
server 10.0.0.3:8080;
# Cookie-based sticky sessions (nginx-plus / sticky module)
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
server {
listen 443 ssl;
location / {
proxy_pass http://backend_pool;
}
}
# Verify the sticky cookie is set on the first response
curl -sI https://example.com | grep -i set-cookie
# Set-Cookie: srv_id=abc123; Path=/; Domain=.example.comFollow-up Questions
- What are the drawbacks of IP-based session persistence?
- How does session persistence interact with health checks and failover?
- Why is externalizing session state to Redis often preferred over persistence?
- How does session persistence affect load balancing fairness across backends?
MCQ Practice
1. What is session persistence primarily used for?
Session persistence (sticky sessions) routes all of a client’s requests to the same backend for the duration of their session.
2. Why can IP-based persistence be unreliable?
Clients behind shared NAT appear as one IP, and mobile clients can change IP mid-session, both breaking IP-based stickiness.
3. What is the recommended long-term alternative to relying on session persistence?
Moving session state to a shared store lets any backend serve any request, removing the need for sticky sessions altogether.
Flash Cards
What is session persistence? — Routing a client’s requests consistently to the same backend server for their session (sticky sessions).
Most common mechanism? — A cookie identifying the previously assigned backend server.
Why does IP-based persistence break down? — Shared NAT makes many clients look like one IP; mobile clients can change IP mid-session.
Better long-term alternative? — Externalize session state to a shared store (e.g., Redis) so any backend can serve any request.