Out of curiosity, if you were to implement the features of Pusher yourself, would it have added too much to your implementation? I guess you would need to set up your own Socket.IO server, and push data from that.
I've never implemented this, which I think is the reason I am underestimating the service that Pusher provides. It would be great if someone that did implement it would convince me that it would be a large hassle to do that internally.
I have come across Slanger[1] while researching for a good websocket server and it worked well for us. It's basically an open source version of Pusher backend. You may be interested in their code.
I haven't used Pusher or Socket.IO, so I don't know specifically what they offer. However, I have made a simple unidirectional websocket-type server and it was not a terrible hassle.
With a go server on a GCE n1-standard-2 you should be able to handle over 100k connections per server. I haven't done any benchmarks for throughput, but using redis as the messaging backend you can do pretty well.
You take 100k connections on each of the endpoint servers and make a single redis connection, using redis pubsub to subscribe to channels. Publishers can connect to the same redis and publish to those channels.
If you wanted bi-directional it could work a similar way I think, I'd guess the specific architecture depends on your requirements.
I've never implemented this, which I think is the reason I am underestimating the service that Pusher provides. It would be great if someone that did implement it would convince me that it would be a large hassle to do that internally.