Unless your app is going to hit massive scales (hint: it won't. the chances that you are one of the few that do is so minuscule, it's not worth assuming it will happen), optimise for simplicity, not scale.
Micro services are the exact opposite of simplicity. What used to be a method call, is now a network request.
With a monolithic application, you have to worry about the application process (which may be Node directly, or may be an application server like Phusion Passenger), and the associated services it depends on: database, caching, possibly http/tls front-end.
With a micro services architecture you have to worry about all those processes for each and every micro service. Sure, they may be sharing a database, but they also may not. They may be sharing a caching layer, but they may not. They may not even use the same caching/database software.
Unless your app already works when one of the four micro services is down, any argument about "single point of failure" is moot, because you currently have 4 single points of failure.
Micro services are the exact opposite of simplicity. What used to be a method call, is now a network request.
With a monolithic application, you have to worry about the application process (which may be Node directly, or may be an application server like Phusion Passenger), and the associated services it depends on: database, caching, possibly http/tls front-end.
With a micro services architecture you have to worry about all those processes for each and every micro service. Sure, they may be sharing a database, but they also may not. They may be sharing a caching layer, but they may not. They may not even use the same caching/database software.
Unless your app already works when one of the four micro services is down, any argument about "single point of failure" is moot, because you currently have 4 single points of failure.