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