Session affinity (Sticky Sessions)

Session affinity ensures that all requests from a single user (or client) during a “session” (e.g., browsing a website) are routed to the same backend server. This is critical for maintaining stateful interactions (like logins, shopping carts) when a website or app uses multiple servers behind the scenes.

How It Works: Step-by-Step

1. Initial Request:
   • When a user first connects to a website/app, their request hits a load balancer (the traffic manager).
   • The load balancer picks a backend server (e.g., Server A) based on a rule i.e. Load balancing strategy like round-robin, least connections, etc.
2. Creating the “Stickiness”:
   • The load balancer assigns a unique identifier to the user to remember their server. This can be done in several ways:
     • Cookie-Based:
       • Session Cookie: The load balancer injects a cookie (e.g., JSESSIONID=abc123) into the user’s browser. This cookie expires when the browser closes.
       • Persistent Cookie: A custom cookie (e.g., SERVER_ID=A) that explicitly ties the user to Server A.
     • IP Hashing: The load balancer hashes the user’s IP address to map them to a specific server.
     • Custom Headers: For APIs/mobile apps, headers (e.g., X-User-ID) can be used to route requests.
3. Subsequent Requests:
   • The user’s browser sends the cookie/header/IP in future requests.
   • The load balancer reads the identifier and routes the request to the same server (Server A).
4. Ending the Session:
   • When the session ends (e.g., user logs out or the cookie expires), the load balancer is free to assign a new server for future requests.

Method	How It Works	Pros & Cons
Cookies	Load balancer/server sets a cookie in the user’s browser.	✅ Reliable. ❌ Requires cookies enabled.
IP Hashing	Maps user IP to a server using a hash function.	✅ No cookies needed. ❌ Fails if IP changes (e.g., mobile networks).
Custom Headers	Uses headers (e.g., X-User-ID) for routing.	✅ Works for APIs/mobile apps. ❌ Requires app support.

Without session affinity , If no cookie/IP binding exists, the load balancer might send your next request to Server B and Server B has no record of your cart → your cart appears empty!

Challenges

• Server Overload: If too many users are “stuck” to one server, it can become overloaded.
• Server Failure: If Server A crashes, users tied to it lose their session (unless servers replicate data).
• Scalability: Harder to add/remove servers dynamically (hashing/IP-based methods can break).

Real-World Fixes

• Health Checks: Load balancers detect crashed servers and reroute users.
• Session Replication: Servers share session data (complex but fault-tolerant).
• Timeouts: Automatically expire sessions after inactivity.