Why does this matter right now?
Imagine a user starts filling a checkout form and suddenly lands on a different server that does not know about their in-progress cart. That breaks trust, increases friction, and hurts conversions – especially on mobile and in regions with spotty networks. Sticky sessions (session affinity) are a simple way to avoid that by keeping a user connected to the same backend instance for the duration of a session.
In this guide, you will learn how sticky sessions work, step-by-step implementation patterns, real code examples, and when to avoid them. Readable, practical, and ready to paste into your project. 🚀
What are sticky sessions? (sticky sessions explained)
Sticky sessions, also called session affinity or persistence, are configuration behaviors in load balancers or proxies that route a client to the same backend server for multiple requests. The affinity is usually based on a cookie, IP address, or another token. This prevents a session’s ephemeral data from being lost across different servers.
Why use them?
-
Prevents lost session state (cart, form progress).
-
Simpler setups when you do not have a shared session store.
-
Useful for small clusters and legacy apps.
Why you might not want them
-
Poor resilience: if the “sticky” server dies, that user's session can be lost.
-
Uneven load distribution if many users get routed to the same server.
-
Not ideal for auto-scaling across geo regions.
Core approaches to implement session affinity (session affinity nginx)
-
Cookie-based affinity — LB sets a cookie that ties the user to a server. Preferred for accuracy.
-
IP-based affinity — routes based on client IP; works but fails for mobile NATs and proxies.
-
Shared session store — best long-term solution: store sessions centrally (Redis, Memcached). This avoids sticky sessions but will require a network round-trip.
Step-by-step guide: Cookie-based sticky sessions with NGINX
This example shows a simple NGINX upstream with cookie-based sticky routing. Many NGINX builds include the ngx_http_upstream_module or sticky module; your distro may vary.
NGINX (conceptual)
upstream backend {
ip_hash; # simple, fallback option (not cookie based)
server 10.0.0.11:3000;
server 10.0.0.12:3000;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
If using a third-party sticky module, configuration becomes:
upstream backend {
sticky cookie srv_id expires=1h domain=.example.com path=/;
server 10.0.0.11:3000;
server 10.0.0.12:3000;
}
Notes
sticky cookieinstructs NGINX to set a cookie and use it for affinity.Cookie path, domain and expiry should match your app and geo needs.
Node.js example: express-session + redis (sticky sessions nodejs, redis session store tutorial)
A robust pattern: use a shared Redis session store so you do not need strict sticky routing.
Install
npm install express express-session connect-redis redis
Server code
const express = require('express');
const session = require('express-session');
const RedisStore = require('connect-redis')(session);
const { createClient } = require('redis');
// Create and connect Redis client
const redisClient = createClient({ url: 'redis://localhost:6379' });
redisClient.connect().catch(console.error);
const app = express();
// Configure session middleware
app.use(session({
store: new RedisStore({ client: redisClient }),
secret: 'change-me-to-a-strong-secret', // use a strong, unique secret in production
resave: false,
saveUninitialized: false,
cookie: {
maxAge: 1000 * 60 * 60 // 1 hour
}
}));
// Example route
app.get('/', (req, res) => {
req.session.views = (req.session.views || 0) + 1;
res.send(`Server instance says hello. Views: ${req.session.views}`);
});
// Start the server
app.listen(3000, () => console.log('App running on port 3000'));Why Redis
Central session store accessible from any instance.
Enables horizontal scaling and avoids per-server session loss.
Works well with multi-region setups when using region-aware Redis or replication.
HAProxy example: sticky sessions with cookies (load balancer session persistence)
HAProxy supports cookie insertion:
backend app-backend
balance roundrobin
cookie SRV insert indirect nocache
server srv1 10.0.0.11:3000 cookie srv1
server srv2 10.0.0.12:3000 cookie srv2
This sets a cookie SRV and HAProxy uses it to route subsequent requests to the same server.
Mobile and Geo-aware considerations
Mobile clients often switch IPs. Cookie-based affinity is better than IP-based for mobile.
For global apps, prefer shared session stores placed in or replicated across regions to minimize latency.
If you must use stickiness across geo regions, be explicit: set cookie domain and consider TTLs to allow failover.
Quick Bootstrap demo (UI) to show session identity on the page
Use this small HTML to show a simple UI that calls the Node.js endpoint and displays server responses. It uses Bootstrap for layout.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Session Demo</title>
<link href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css" rel="stylesheet">
</head>
<body class="p-4">
<div class="container">
<h1 class="mb-3">Session Identity Demo</h1>
<div id="output" class="alert alert-light">
Click to check session
</div>
<button id="btn" class="btn btn-primary">Check Session</button>
</div>
<script>
document.getElementById('btn').onclick = async () => {
const res = await fetch('/');
const text = await res.text();
document.getElementById('output').textContent = text;
};
</script>
</body>
</html>
Run the Node server above and open this HTML to see the session view counter and confirm whether requests go to the same backend.
Best practices and checklist
Prefer a shared session store (Redis) for scalable systems.
Use cookie-based affinity only if migrating legacy apps or when a shared store is not feasible.
Set sensible cookie
SameSite,Secure, and TTL attributes for security and geo compliance.Monitor backend server load; enable sticky session metrics to catch imbalance.
Design for failover: store critical data (orders) in durable storage, not only in memory sessions.
When to avoid sticky sessions
You need true stateless microservices.
You auto-scale aggressively and want even load distribution.
You must guarantee zero single-server session loss without replication.
Ending note
Sticky sessions are a practical tool in the engineer toolbox. Use them deliberately: cookie-based affinity for accuracy, shared stores for resilience, and clear monitoring to avoid hot servers. Stay tuned for more detailed how-to guides and sample repositories that walk through deployment patterns and geo-replication strategies. ✨
FAQs for Sticky Session Concept
1. What are sticky sessions and why are they used?
Sticky sessions, also known as session affinity, tie a client to the same backend server across multiple requests.
They’re used to prevent session state loss when session data is stored in-memory on a specific server instance.
2. How do cookie-based sticky sessions work?
A load balancer or proxy sets a cookie on the client that identifies which backend server handled the request.
Subsequent requests containing that cookie are routed back to the same server.
3. Are sticky sessions secure for production apps?
Sticky sessions themselves aren’t inherently insecure, but:
Always secure cookies using
Secure,HttpOnly, andSameSiteflags.Avoid storing sensitive or long-lived data in ephemeral in-memory sessions.
Consider combining stickiness with a shared or persistent session store.
4. How do sticky sessions compare to shared session stores like Redis?
| Sticky Sessions | Shared Session Store (e.g., Redis) |
|---|---|
| Simpler to configure | Requires external service (Redis/Memcached) |
| Session data local to one server | Session data centralized and shared |
| Limited scalability | Enables true horizontal scaling |
| Risk of session loss if server fails | More resilient and durable |
5. Can sticky sessions handle mobile users with changing IPs?
✅ Yes — cookie-based sticky sessions handle changing IPs gracefully.
❌ IP-based affinity can break for mobile clients that switch networks.
6. What happens if a sticky server goes down?
If the “sticky” backend server fails, the user may lose any in-memory session state.
To prevent data loss:
Use a replicated or durable session store (like Redis).
Minimize critical state stored only in memory.
7. Which load balancers support sticky sessions?
Many modern load balancers and proxies support session affinity, including:
NGINX (with sticky module or
ip_hash)HAProxy (via
cookiedirective)AWS ELB / ALB (with stickiness cookies)
Traefik, NGINX Plus, Kubernetes Ingress controllers, and others
Choose based on your infrastructure, performance needs, and scalability goals.
Discover more from 9Mood
Subscribe to get the latest posts sent to your email.
0 Comments