Thanks for the response! We went with Node.js instead of connecting the client directly to Rabbit primarily because of socket.io.
So far the amount of activity has been extremely underwhelming for the node instances, but we'll see if this changes over time. The current total activity amounts to <100 activities per minute, and I'm pretty sure we could support at least an order of magnitude more than that. Each node box has identical state at all times to all of the others, with the exception of currently connected socket.io clients.
Honestly the first thing I would do if we had the need to scale horizontally (scaling only for HA for now) would be to reduce the amount of data sent over the wire at all levels. I'd modify the current solution of sending the entire object to send only a reference to the object and what amounts to a diff of old version to new version.
I'm pretty new at architecting stuff like this (this project was my first time making architecture decisions), so I'm sure there's plenty of room for optimization. I'm just hoping that it was architected in a way such that if/when it fails due to load, very little of the code will need to be rewritten. However, given current performance, the increase in amount of activity that would be required to overload our architecture seems like one of those 'Good Problems to Have'.
So far the amount of activity has been extremely underwhelming for the node instances, but we'll see if this changes over time. The current total activity amounts to <100 activities per minute, and I'm pretty sure we could support at least an order of magnitude more than that. Each node box has identical state at all times to all of the others, with the exception of currently connected socket.io clients.
Honestly the first thing I would do if we had the need to scale horizontally (scaling only for HA for now) would be to reduce the amount of data sent over the wire at all levels. I'd modify the current solution of sending the entire object to send only a reference to the object and what amounts to a diff of old version to new version.
I'm pretty new at architecting stuff like this (this project was my first time making architecture decisions), so I'm sure there's plenty of room for optimization. I'm just hoping that it was architected in a way such that if/when it fails due to load, very little of the code will need to be rewritten. However, given current performance, the increase in amount of activity that would be required to overload our architecture seems like one of those 'Good Problems to Have'.