I was reading a litte about clusters in nodejs, and in all cases it was trivial to clusterize the application. In fact, it was so easy that I began to wonder: are there any cases that I shoudn't use clustering?
Several possible downsides or issues you have to code for:
Login sessions must either be stored in a central database (such as redis) that all clusters can access or connections must be made sticky so that a given client goes back to the same cluster process every time.
Other server side state is either maintained separately by each clustered process or needs to be moved to a separate database server that all clustered processes can access.
Socket.io connections will not work properly unless you force webSocket from the beginning or make connections sticky.
To run socket.io on a cluster, you will need to run the clustered adapter that can appropriately find the right connection on whatever clustered instance it is connected to.
Updates to shared state in a separate process are not immune to race conditions when you have multiple node.js processes all able to access it so you have to code shared state updates appropriately to avoid race conditions.
Using the debugger can be significantly more complicated, particularly when trying to track activity in several successive requests (because each request may end up in a different process).
All of these issues can be handled with managed or solved with extra coding or installation and configuration of extra modules (at the cost of extra complexity).
are there any cases that I shouldn't use clustering?
When you don't need it. It's an extra complication. So, following the general guidelines of make your code only as complicated as needed, you shouldn't use clustering if you don't really have a need for the extra scale.
You also wouldn't generally use clustering if you didn't have multiple cores in your CPU.