As both an IC and Manager, I've now been on a lot of teams using monoliths and teams using microservices, and I would always choose microservices going forward.

As both an IC and Manager, I've now been on a lot of teams using monoliths and teams using microservices, and I would always choose microservices going forward. Let's be straight, both have pros and cons, but I value the following pros of microservices a lot more than any of the cons: - Enforces separations that are important for: - Maximum parallelization of work. - Scalability of each service. Never share database. - Reusability of the service from other services. The trick is to learn how to cut microservices though. Establish an interface that it exposes, like GraphQL or RPC. Don't try to split too fine-grained, but find a balance that works for you. I promise you, when it comes to scalability, you'll be glad you don't have to scale one massive database just because one part of your application is seeing more activity. This also allows you to pivot quicker to a different database suddenly, or a different programming language, if requirements change. E.g. Node.js -> Rust if your service is found to be on the hotpath of everything, and you need correctness and performance. I fundamentally view the difference the same way I would choose Rust over Clojure: - Monoliths: Rely on discipline of the team to do it right (like Clojure won't catch your dynamic mistakes) - Microservices: The most important parts you need are built-in and enforced by the concept itself (like the Rust compiler guides you towards the correct approach).