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.
Comments
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.
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.