should highscalability high-realtime (max tens of milliseconds allowed for response) business logic stateless or stateful?

Question

I know it sounds very general question, but i'm really interested in having stateless services i want to know if it can or cannot be done with these limitations (stateless). for example google has many services. I'm more concerned about the services where they need to return results very very fast (a few tens of milliseconds at most) and they have huge data scattered (maybe they keep a summary someowhere for immediate). in these cases can anyone tell if their "business logic" servers are stateless or statefull? stateless might have the benefit of simplicity moving the state to the storage layer (gfs/memcached/bigtable) however with stateful if you transfer the requests to same node then you could have the result in a snap from internal memory. anyone has experience with this kind of huge scalability huge realtime issues?

Answer 1

As noted stateless services are easier to scale - but you should note that Stateless means you make the state someone else's problem (the DB, the distributed cache etc.) If they can handle the load and the latencies, bandwidths etc. are all supportive you can afford to make your service stateless and get the benefits.

If, within the constraints of your project (e.g. budget) you can't have someone else solve the state problem you'd have to make your services stateful

Answer 2

Only stateless. Stateful services services are very hard to scale as you have to deal with synchronization of state in that case.