Earlier quoted context omitted.
If you have 140M active users, handling a fleet of 1000 servers is not an easy operation, considering you need to manage inter-cluster communications (i.e. when sender and receiver sockets fell on different servers). I've built Erlang/OTP websockets clustered server, which can handle 3M per node (giving you have enough RAM). Here you handle all your users with "only" 47 servers. There is a big operational and scaling…
I'm a bit curious about this. If you have 140M concurrent users (since this was the original complaint) and you are NOT prepared or capable of servicing/monitoring/maintaining 1000 servers, that seems like a fatal flaw in your server management and analytics processes. Certainly 47 servers vs. 1000 is far nicer. But at 140M concurrent users levels (there must only be a few handfuls of sites with these types of concer…
Nodes in the cluster need to communicate with each other and with other systems, like databases, message queues, monitoring servers, etc.
You can aggregate data per node, so the less servers in the front-end cluster you have, the less load on the back-end servers.
There is also financial problem: many organizations can afford 50 servers. But not many can afford 1000 servers.