Do we really need sticky sessions?

I was looking into Socket.io and Primus etc. and I now know that sticky sessions are only used for clients that fallback to polling from websockets. If that’s the case, since we’re building SPAs with Meteor (which uses Sock.js - is this real websockets?!) for modern browsers, shouldn’t we assume that websockets are a requirement and thus we can eliminate the need for sticky sessions altogether and use something like JSON Web Tokens to auth requests against any server in a cluster, as they can be stateless? I personally don’t mind having a requirement on Redis to keep the clustered clients in sync.

1 Like

So every server should keep every user’s DDP cache for all DDP connections in cluster? :smiley:

2 Likes

My understanding is that the upgrade to websockets itself also requires sticky sessions or else your load balancer may send the upgrade request to a separate backend server. Pretty sure we saw that happening when we were first testing our prod setup.

Yes, but if our backend servers aren’t maintaining client state (stateless API), and we use JWTs for auth, then it won’t matter what server they hit. If state is required on the server, then perhaps using Redis to share state so clients can hit any app server would be a good approach?