Does stateless only transfers client's state to somewhere else?

Question

I have spent a whole day understanding what stateless architecture is. I read many posts and answers like

Can My Web App Implement User Login and Remain Stateless?

Pros and Cons of Sticky Session / Session Affinity load blancing strategy?

http://www.quora.com/What-is-stateless-and-statefull-web-architecture

• It seems that stateless is only transferring some user state to somewhere else(database/memcache or client cookies).Is this right? If yes, the state is only stored somewhere else, so there must be something that is not stateless(client or server), though the load balancer now does not need to worry about which machine to route .

• If above is right, if we choose transfer the user information to central place(transfser to client seems not always be the solution according to some answers) like database or memcache , we still need to find this session info for every requests. That means the place where holds the user state will have the same pressure on handling tens of millions requests at the same time. And probably, the way we find the the session information is just like sticky session(route the information request into a single node in the memcache). So why do we consider transferring the state is more scalable? The pressure is only transferred(And always, database has already had too much load)

Do I miss something or understand wrongly?

Thank you!

Tameratamerlane

The user state can stay in the client, provided that the client can make meaningful calls to the server without violating any business rules. – Bryon

@AshleyFrieze, yeah, but somethimes it is not a solution for some sensitive or large user state, isn't it? – Tameratamerlane

Are we talking state? or data? You can have persistence services for storing things. State is more commonly a kind of "what are we up to now" thing, rather than just "everything the user has typed in so far". – Bryon

@AshleyFrieze, transfering to the client side is a choice, but not always, like #20588967. So for now, we still use central place to store the state ,which is the main concern in my question – Tameratamerlane

Answer 1

You are correct in that moving your state to a different layer means your application is stateful (there are very few truly stateless applications, mostly only ones doing pure math).

That doesn't mean individual layers can't be stateless, and those layers that are will scale differently than the stateful layers. The idea is that by making a particular part of the application stateless, you will be able to scale it horizontally, instead of vertically, thus able to respond to many more requests by simply buying more hardware.

You will still need to scale wherever you push that state to. So if you are are pushing it out to a database, you will need to be able to scale that database accordingly. This works well if you can push it out to a layer that can be scaled cheaply (like memcached).

It is often the goal to make your business and web layers stateless because they are generally much more expensive to scale than your data-store layers, but this isn't always true. If you have put a lot of load on your data store layer, and very little load on your application or web layers (like a data-driven vs an interaction-driven app, then you will overload your data layer.

So, like everything else, whether to make your application stateless comes down to "it depends". Generally, stateful business and web layers tend to get overloaded long before data layers do. Especially if you are doing significant OOP.

Gavelkind

Thank you! So, in you r opinion, price/ease to scale is the most important factor to transfer the state? But what i confuse is that(take db to store state as an example), database will always will have to much load and need reducing load, so if we transfer the "pressure" to db, why is this considered more easy/better to scale? The same questions on memcache.The above confuses me most, would you please update your answer and put it more details on this? Thank you! – Tameratamerlane

The database often does not have more load. Even if it does, you can usually refactor it to split the content into multiple tables that can be spread over multiple machines. In fact performance usually increases as you do this. Database performance is usually more about disk IO than memory/cpu. On an application/web server though, you are naturally not able to fragment the domain any smaller than that which is required to service the request. This establishes a minimum "sharding" to service a user's session that is usually very close to your domain size. – Gavelkind

There are also reliability constraints. Database servers (and definitely memcached) tend not to go down nearly as often as application servers. This is mostly because database servers are both more mature, and don't have programmers writing significant application code against them that brings them down (like application servers do). I have seen database heavy applications where developers insist on writing huge stored procedures, or complex joins which cause instability in the database layer... but I've seen far more infinite loops or out of memory errors in app servers. – Gavelkind

What about performance? Will performance be better after we transfer the presure? Why? Would you please update to your answer and I will accept it. Thank you! – Tameratamerlane

Once again, "it depends". Performance will scale more linearly on the layer you made stateless. That doesn't mean each requests will be faster, it just means that you can handle more load by adding more machines. But if you are already choked on database, it will make that problem worse. Stateless app layers are not a magic bullet. The best way to find out is to throw a load testing tool at your application, and find out what falls down. – Gavelkind