I believe the whole purpose of putting session data into cookies is to prevent the other issues that arise when storing session data on the server's database. The main issue is that when you're load balancing, each request could be load balanced to a different server, so you need the session to be stored on the client side to prevent the hassle of trying to scale your back-end to use your solution.
> I believe the whole purpose of putting session data into cookies is to prevent the other issues that arise when storing session data on the server's database. The main issue is that when you're load balancing, each request could be load balanced to a different server,
When you are load balancing, request 1 goes to web/app server 1, the app server reads the session id from the cookie and read the session from the db..the next request goes to web server 2, web server 2 reads the session id from the cookie, loads the session from the db...
Each request being load balanced to a different web/app server doesn't affect the session. You are going to read the session id from the signed cookie, and then load the session from the db which is being shared between all of your web/app servers.
you assume that the load balancing doesn't balance across db's as well. I assume if your app needed load balancing, there is justification to shard it across different DBs too.
> I assume if your app needed load balancing, there is justification to shard it across different DBs too.
Having 2 or more web/app servers sharing a db is a very common setup. Db sharding is more of an exception than a norm.
Even then, db sharding doesn't affect sessions unless your sharding parameter is if the request is on web server 1, then load from shard 1(which doesn't make any sense). The code which decides which shard to query is common on all web servers and it will hit the required shard regardless.
Or use sticky sessions and keep the session state server side... Much faster than rebuilding session state for every request (whether from a cookie or from a DB), especially the more complex your app and session state become.
In my experience, sticky sessions open a whole new can of worms. With proxies and VLAN, it's very easy to have an extremely unbalanced load if you use naive IP-based balancing. If one of the servers becomes a "hot spot", adding more servers won't immediately remove the load from that. And when a server dies, the sessions in that server are lost. These problems can be mitigated with an in-memory distributed database overlaid on top of your cluster, but that opens its own can of worms...
Apache and nginx both have an array of good LB algos. I've never seen IP-based LB or hot-spots really. Most app servers support session replication/backup to other node(s). This is really standard stuff in JBoss for instance (my world). Problems that have been solved for years and used at massive scale.
I am assuming by "keep the session server side", you mean keep it in the RAM. If you want to keep the session in the ram, store it in memcache or redis.
Also, the more complex an app becomes, it's generally desirable to have less state, not more(as in sticky sessions).
I'm not sure I agree with either of your points. Sticky sessions with in app/JVM/whatever RAM session objects is much faster than pulling from memcache/redis and parsing/deserializing/instantiating the session state for each request.
Not at all sure what you mean by your second point. Sure generally simplifying things is desirable, but by complex app, I mean an app that has requirements that are complex, and many of those apps require additional session state. For instance keeping track of all categories and products browsed to target recommended products. Keep track of users' site browsing preference, search results, multi-tab interaction, etc...
