Best practices for load balancing node.js app on google cloud

Six long years and nobody has ventured a response. Well, I've got a bit of hindsight to complement experience so I'll proffer one.

Q1. Maybe. If you don't mind adding the complexity of cluster to your app, and you're careful to avoid anything that might throw in the master process, then cluster works great. Otherwise, you certainly want something to handle supervising your node process and restarting it when your app crashes. Your OS might provide alternatives such as daemon or systemd.

Q2. No. At best, on a good day with the wind at its back, node-http-proxy is almost as good as nginx or haproxy. Excluding SSL where both haproxy and nginx are much better. It'd be awfully hard to build a case for it being more suitable.

Q3. Yes, or haproxy. Until you have the need to introduce varnish. When you get to that point, you won't have to wonder if you should be using varnish. (Or you'll use a CDN).

Q4. Your call. Haproxy is my default tool of choice for TLS termination and proxying. I don't hate myself enough to put something as critical as a load balancer on someone else's server where I can't run tcpdump or other troubleshooting tools.

1. Yes. If you known nginx well, then use it to handle the HTTPS termination and proxying the requests to your app servers. If you aren't heavily into nginx already, consider haproxy instead. With a name like haproxy, you'd expect it to be really really good at HA and proxying and it doesn't disappoint.

2. haproxy / nginx. Always. Better certificate management, listing at cipherli.st, etc. There's also less impact to your app to upgrade the proxy when openssl vulnerabilities are released.

3. haproxy. (nginx supports proxying websockets now, so this question is past it's expiration date).

4. Multiple sites and BGP. Introducing tools like keepalived or other peer-to-peer TCP failover mechanisms to your stack is just as likely to be the cause of an outage as to prevent one. The use of such tools is typically rare so the human with site knowledge of it is out of practice when the necessity arises. Keep the stack simpler and depend on the skills of your network team. They are well practiced at routing around problems.

I think it is useful to do this.

nginx has a lot of code to shovel files efficiently from the disc to the network socket in a non-blocking way. It does this much more efficiently than node.

Of course, if you're not doing much static content serving then it might not be useful.

But nginx can also load balance over multiple node servers, so that's another potential advantage. Your app has to be written to be scalable like that though.