The whole thing could be trivially built as a monolith on Rails/Django/Express. But that's not exciting.
The best place to place a module boundary - and the best format for communication across that boundary - is rarely completely transparent from the outset. With a monolith it's relatively easy (if not actually easy) to fiddle with those details until you get them right. With a service it can be very difficult to iterate on this stuff, so unless you're very confident you'll get it right on the first try, it's best to get a bit of experience in the problem domain first.
The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the software are so inextricably linked that it is not portable in the least bit.
You can bundle up those complex dependencies into deployment manifests, or use helm.
It's like a SAAS in a box
Yeah it's not new fun tooling, but boy does it feel good to ship features without it being a total pain in the arse.
Also C# is pretty nice.
Several sites I'm aware of have an Facebook-style chat service, which is basically an off the shelf node app on its own. This makes far more sense than trying to build such a thing into their legacy app. It also perfectly describes a very useful micro service, in a very different environment to yours.
ha. I wish I had this many repos. We have 1000+ git repos. To be fair, a ton are open sourced and there are reasons why it's done this way, but still.
Reality: Everything runs on two EC2 instances, regardless of load.