Load Balancing And Sticky Sessions

Question

According to what I understand , the use of sticky-sessions is to route user to the same backend so they won't have to for example login again each time they are re-routed or if they have a shopping cart , they won't lose their items etc. But I also know that it's best practice to not store state on backend servers and in this case, it's recommended to store the session in a DB or in an in memory DB . Is that correct ? if so , is there any point in using sticky-sessions when storing state in a DB for example ?

Answer 1

The purpose of sticky-sessions generally is to make sure the user is directed always to the same backend, provided that the backend is up (and generally you would want the user to go to any other backend if its down!)

With that in mind, if the backend fails, restart, or goes away, is being upgraded or has issues, your user end up on a different backend, so if you store session data on the backend only, then the user lose his session data (has to relogon, lose his cart, etc).

So in all cases, sessions need to be either replicated between backend (if kept in backend's memory) or kept in a session store like Redis, Memcached, RDBMS, etc. If you don't then you have a relatively poor service level.

Now, is sticky session needed even if you keep the session in a session store external to the backend?

That really depends on your environment, architecture, design, etc. It may make sense for you, or it may not be necessary.

There may be other things than a session that may warrant using sticky sessions. Say you have a web service that processes a file. The user uploads the file and it's being processed by one of the multiple backends. Subsequent to the initial calls, additional calls are being made to check the status of the processing of the file. The requests for status need to go to the backend that is processing the file. Sticky session would help with that. If the backend dies, of course the file processing stop and the next status request returns something like "your job no longer exist!".

Of course, you could also store the status updates in a database (like a Redis or other similar things) and then the status requests can go to any backend. But that's more complex and more complexity is not always warranted.

Generally, I would say if you have a very small setup, small user base, sticky session is generally better than a more complex infrastructure with a session store. You would be running multiple backend presumably for maintaining a high uptime. So if you have an external session store, you have to make that HA too... now complexity of your system increases.

That's what I like with IT - for everything, it depends...