Sticky Sessions and Session Replication

Sticky Sessions:

Traditionally, web servers used to store HTTP sessions in web applications. These sessions would store user data for a specified time frame (which is known as session time out).

Load balancers generally support a feature known as ‘Sticky Sessions’ (Also known as ‘Server Affinity’). If this feature is turned on, the load balancer remembers which server was assigned to which session (based on session Id or client’s IP address). The load balancer would route all the future requests within a time frame to the same server.

The time till which a load balancer remembers (or persists) this information should be ideally more than the server’s session time out.

If a load balancer server goes down, the users connected to it lose their session.

Relevance of Sticky sessions in Cloud Architecture:

Sticky sessions are not preferred in cloud based architecture as we will have a huge number of application servers which are spawned and torn regularly. Maintaining sticky sessions would defeat the purpose of scaling, as requests might be unevenly balanced since the requests would hit the same set of servers based on server affinity.

Session Replication:

Instead of sticky sessions, a concept known as ‘Session Replication’ is preferred in cloud based systems. In Session Replication, the HTTP session is not stored along with the application, but is generally stored in a distributed cache (like for instance Redis). Since the session is stored in a distributed server, we can scale the application horizontally without worrying about maintaining the session state.