Generally, a load balancer distributes each incoming request independently amongst the group of servers behind it. There are different algorithms to determine the distribution path of traffic. Such algorithms are round-robin, weighted round-robin, least connections, weighted least connection, etc. The load balancer evenly distributes the requests to the most suitable and available servers. It also ensures that the system does not overwhelm one server with traffic when the other servers remain idle.
However, this mode of load balancing is not always adequate. We can have requirements to bind all traffic from a single user session to one single target server. The load balancer will distribute the first transaction to one server (based on a chosen algorithm). It’ll then bind subsequent traffic (from the same user session) to the same server. We use the Session Affinity load balancer feature to achieve this system behavior. It sends all subsequent traffic from a user session to the same target server where it transmitted the first request.
We interchangeably use terminologies like session affinity, sticky session, or chatty session.
What are the use cases of session affinity in load balancer?
I could gather the following two good use cases of session affinity:
- Session affinity is helpful in situations where we maintain the state information of user actions on the server-side to provide a seamless experience for the subsequent steps taken by a user.
- Consider a situation where we need to read some information from the database and use it in a series of steps the user takes in the same session. Repeatedly reading from persistent database storage causes delay and may not be the perfect user experience. So, we can read from slow persistent storage once and store it in the local cache for subsequent requests as an alternative. We can use the session affinity feature of the load balancer to route all the subsequent traffic to the same server where it sent the first one.
- Let’s take one concrete example. When a user logs in to a portal, we retrieve his basic profile information from the database for the need of the user landing page. Subsequently, if the user clicks on address information or saved payment information, we’ll make a few more API calls to the backend to fetch relevant data. So, for each such action, if we perform disk I/O in the form of a database lookup, the system performance will be bad. Instead, we can store the profile information in the local server cache when the user logs in. We can send the traffic to the same server using the session affinity feature and fetch the data from the in-memory cache for subsequent API calls.
What are the benefits of session affinity?
Session affinity benefits us in multiple ways:
- Good utilization of local in-memory caches
- Better performance of the application
- Improved user experiences
- Reduction of costly disk I/O
- In the absence of session affinity, there would have been a need to exchange user-session information between servers. Or, there would be a need for an expensive and complex implementation of a global cache. But with session affinity, we can reduce these costs.
- The session affinity is a load balancer feature. So, the applications can concentrate on the core business without worrying about user sessions. Thus, the overall solution becomes simpler.
References
- https://kemptechnologies.com/glossary/session-affinity/
- https://docs.oracle.com/cd/E29584_01/webhelp/PerfTuning/src/cperf_load_balancing_and_session_affinity.html#:~:text=Session%20affinity%2C%20also%20known%20as,in%20the%20load%20balancer%20pool.
- https://avinetworks.com/glossary/session-persistence/
- https://kemptechnologies.com/glossary/session-affinity/
