Microservices was always a solution to the organisational problem of getting more developers working on a system at once. A lot of people working on one code base over the top of each other often causes problems and issues with ownership. The solution was services independently developed with the trade off cost being increased complexity on a range of things.
There is an essay in the mythical man month about Conways law and microservices are very much about a way to use Conways law to achieve scale of development. You likely don't need microservice until you hit a scale where the monolith is a real pain point. You can probably cope with a monolith especially with some reasonable design effort up to the 100 developers maybe more with a lot of separation but at some point in the >25 developers range it becomes cheaper and easier to switch to multiple deployed units of software and deal with the increased system complexity and interface designs and the inherent versioning issues it causes.
It is easier to start with a monolith, find the right design and then split on the boundaries than it is to make the correct microservices to begin with.
There is an essay in the mythical man month about Conways law and microservices are very much about a way to use Conways law to achieve scale of development. You likely don't need microservice until you hit a scale where the monolith is a real pain point. You can probably cope with a monolith especially with some reasonable design effort up to the 100 developers maybe more with a lot of separation but at some point in the >25 developers range it becomes cheaper and easier to switch to multiple deployed units of software and deal with the increased system complexity and interface designs and the inherent versioning issues it causes.
It is easier to start with a monolith, find the right design and then split on the boundaries than it is to make the correct microservices to begin with.