Module 4 — Scaling
Session Management
How to remember users across requests in a distributed system.
1The Hospital Wristband Analogy
💡 Simple Analogy
At a hospital, you get a wristband with ID. Any nurse can scan it to see your records.
Wristband = Session ID (cookie or token)
Hospital database = Session Store (Redis, DB)
The wristband doesn't contain your medical history—it's a reference to look it up.
Wristband = Session ID (cookie or token)
Hospital database = Session Store (Redis, DB)
The wristband doesn't contain your medical history—it's a reference to look it up.
2Session Storage Options
Server Memory (Bad)
Store sessions in app server memory
Pros: Fast, simple
Cons: Lost on restart, can't scale horizontally, sticky sessions required
Verdict: Avoid in production
Database
Store sessions in SQL/NoSQL database
Pros: Persistent, queryable, familiar
Cons: Slower than memory, DB load increases
Verdict: OK for moderate scale
Redis (Recommended)
Store sessions in Redis cluster
Pros: Fast, built-in expiry, scales well
Cons: Extra infrastructure
Verdict: Industry standard
Client-Side (JWT)
Store session data in signed token
Pros: No server storage, truly stateless
Cons: Can't revoke, size limits, payload visible
Verdict: Good for short-lived auth
3Redis Session Flow
1
Login: User authenticates → Server creates session → Store in Redis with TTL
2
Session ID: Server sends session_id as HTTP-only cookie
3
Request: Browser sends cookie → Server looks up session in Redis
4
Activity: Extend TTL on each request to keep session alive
5
Logout: Delete session from Redis → Cookie cleared
Redis Session Example
// Store session
await redis.setex(
`session:${sessionId}`,
86400, // 24 hour TTL
JSON.stringify({ userId: 123, role: 'admin' })
);
// Retrieve session
const session = await redis.get(`session:${sessionId}`);
// Extend on activity
await redis.expire(`session:${sessionId}`, 86400);
// Logout
await redis.del(`session:${sessionId}`);4Security Best Practices
HTTP-Only Cookies
Prevent JavaScript access to session ID (XSS protection)
Secure Flag
Only send cookie over HTTPS
SameSite
Prevent CSRF by restricting cross-site cookie sending
Short TTL
24h or less for web, shorter for sensitive apps
Regenerate on Login
New session ID after authentication
Secure Random ID
Use cryptographically secure random generator
5Sticky Sessions (Avoid If Possible)
Sticky sessions route a user to the same server for all requests. The load balancer remembers which server handled the first request.
Why People Use Them
- • Quick fix for stateful servers
- • Legacy applications
- • WebSocket connections
Why to Avoid
- • Server death = session loss
- • Uneven load distribution
- • Complicates scaling
Better Approach
Use centralized session storage (Redis). All servers can access any session. No sticky sessions needed.
6Key Takeaways
1Store sessions externally (Redis) for horizontal scaling.
2Use HTTP-only, Secure, SameSite cookies for session IDs.
3Redis with TTL is the industry standard for session storage.
4Avoid sticky sessions—they prevent true horizontal scaling.
5JWT is stateless but can't be revoked easily.
6In interviews: discuss session security and scaling implications.