Part of the problem is you don't necessarily understand the problem domain very well when you're starting out. There are plenty of examples of microservice architecture failures due to incorrectly dividing services- either causing too much internal communication for performance acceptance criteria, or struggling with service coordination when performing changes that impact multiple relationships.
You may well end up throwing away some or many of your early microservices as you grow and the company better understands what it wants to build.
Or, you can take another approach (which i have witnessed first hand), throw it all away and go back to a regular, well designed monolith and getting very significant performance improvements by doing things like SQL joins and transactions instead of putting events in a message queue and paying network traffic penalties.
You may well end up throwing away some or many of your early microservices as you grow and the company better understands what it wants to build.
Or, you can take another approach (which i have witnessed first hand), throw it all away and go back to a regular, well designed monolith and getting very significant performance improvements by doing things like SQL joins and transactions instead of putting events in a message queue and paying network traffic penalties.