You may want to check first what defines a stateless application. In essence, a stateless web application, as opposed to a stateful web application, doesn't keep its information between multiple requests in memory on the servers, but relies instead on the database, an external cache system, etc.
What's the problem with stateful applications? Imagine a blog engine which relies on in-memory cache in order to store the generated pages, one cache entry per article. When somebody changes an article, the cache is invalidated. It works well if you host the blog on one server. If, on the other hand, you start having multiple servers, then the cache invalidation may go to one of those servers, while the other ones would continue serving obsolete version of the page—some of the visitors will see the new article, and some other would still access the old one.
State, therefore, prevents an application from being hosted on multiple machines (or even multiple processes in some cases), and being stuck with a single process on a single machine prevents to scale the application. With the increasing number of users, you'll need more powerful server to host the app, and at some point, you won't be able to cope with the load.
How do I know if my nodejs application is stateless or not?
If you developed the application, you should know it already, now that you understand what stateless means.
If you didn't, study the code. Check how the variables are used. Are there global variables? Something kept between the requests?
A good starting point is to check the following parts:
- Authentication.
- Session.
- Cache.
This is where you find state most often. If you don't see any stateful behavior here, this doesn't necessarily mean that the application is stateless. If it wasn't written with statelessness in mind, chances are, it isn't. One nice way is to actually host it on several nodes, and see what's happens. It never gives you the definitive answer as to whether it's stateless or not, but sometimes it becomes very clear very quickly that state is involved.
I wanted to know how using socket or "local session-memory" made a nodejs app "stateful"
If by local session memory, you mean actual global variables in your JavaScript code, then yes, the application is stateful.
As for the sockets, I'm not sure if you talk about the actual sockets, or if you mistyped WebSocket protocol. In the case of the sockets, it has nothing to do with state. In the case of WebSocket, it all depends on the way the message queue is implemented. You can have a fully stateless implementation which relies on a message queue service or Redis pub-sub, as you can have an ersatz of a queue in a form of a global variable, which implies that the app is stateful.
