Infrastructure
Design Sticky Sessions
Sticky sessions ensure a user's requests are routed to the same server instance throughout their session. This design covers load balancer strategies, session replication, and failover mechanisms.
- Problem β Stateful applications need request affinity
- Solution β Load balancer routing with session persistence
- Trade-off β Simpler state management vs load imbalance
Sticky sessions are a pragmatic solution for legacy applications that cannot be made stateless.
What Are Sticky Sessions?
DfSticky Sessions (Session Affinity)
Sticky sessions route all requests from a given client to the same backend server for the duration of a session. The load balancer maintains a mapping table: client_id β server_id. This ensures session state (in-memory shopping carts, user context) remains local.
Why Sticky Sessions?
Sticky sessions solve the problem of distributed state. When application state is stored in server memory (not externalized to Redis/DB), requests must hit the same server. This is common in legacy monoliths and Java servlet applications.
Load Balancer Strategies
IP Hash Routing
Here,
- =Client IP address
- =Number of backend servers
IP hash has a problem: NAT and load balancers mean many users share the same IP. This causes uneven distribution. Cookie-based affinity is more reliable.
Cookie-Based Affinity
Here,
- =Unique session cookie
- =Number of backend servers
Session Replication
Replication Strategies
DfSession Replication Approaches
- Sticky with Local State: Session stored only on assigned server. Fast but fragile.
- Sticky with Replication: Session replicated to 1-2 backup servers. Better failover.
- Sticky with External Store: Session in Redis/Memcached. Best reliability, slight latency.
Failover Scenarios
When a server crashes, all sessions on that server are lost unless replicated. Options: (1) Redirect to a new server with empty session (user must re-login), (2) Load from replicated backup, (3) Load from external session store.
Session Recovery Time
Here,
- =Health check interval (5-30s)
- =DNS/LB propagation (0-5s)
- =External store lookup (< 10ms)
Trade-offs
| Aspect | Sticky Sessions | Stateless |
|---|---|---|
| State Management | Simple (in-memory) | Complex (external store) |
| Load Balance | Uneven (hot servers) | Even distribution |
| Failover | Session loss risk | Seamless |
| Scalability | Limited by session state | Horizontal scaling |
| Complexity | Low | High |
When to Use Sticky Sessions
Use sticky sessions when: (1) Migrating legacy apps that store state in memory, (2) Applications with expensive-to-reconstruct state, (3) WebSocket connections requiring persistent affinity. Prefer stateless designs for new systems.
Practice Exercises
- Design: How would you implement sticky sessions with automatic failover when a server crashes?
- Scale: Design a sticky session system for 10M concurrent users across 100 servers.
- Migration: How would you migrate from sticky sessions to a stateless architecture without downtime?
- Consistency: Design a session replication system with < 100ms propagation delay.
Key Takeaways:
- Sticky sessions route requests to the same server using IP hash or cookies
- Session replication options: local, replicated, or external store
- Failover requires either session loss acceptance or external session storage
- Sticky sessions create load imbalance; prefer stateless for new systems
- External session stores (Redis) provide the best balance of simplicity and reliability
What to Learn Next
-> Load Balancing Distribution algorithms and strategies.
-> Caching Strategies Distributed session caching.
-> Circuit Breaker Server failure handling.
-> Retry Patterns Resilient session recovery.
-> Sidecar Pattern Service mesh session management.
-> Strangler Fig Migrating from sticky sessions.