> So we're sending a new data model in the form of JSON over TCP using AMQP? Or are we using STOMP over websockets? Who maintains the broker? Do we use a direct

> So we're sending a new data model in the form of JSON over TCP using AMQP? Or are we using STOMP over websockets? Who maintains the broker? Do we use a direct exchange or topic exchange? How do we replicate messages across exchange nodes to ensure uptime? How do we upgrade the broker? Uh? I don't know? Like, I know how I've done it, idk how you want to do it, and I won't prescribe implementation details as if they're universal. > Monolith, basic high availability is 3 servers, minimum. Now every single microservice needs 3x servers, plus autoscaling, plus we need things like distributed logs, a resilient broker, etc. Even simple things like uptime pinging are more expensive because we're tracking more hosts. If you can run your entire project on 3 systems, yeah, sounds like a case where splitting out would be more expensive. Though you can do microservices without having separate hardware - just stick them on the same box. You still get software fault isolation. > Sure, if you ignore everything outside of your system then it's really easy to work on a single microservice, and if your startup has several million dollars and hundreds of engineers - great, use microservices. That seems like an exaggeration.