I don't really care about service size. I care about service division across logical boundaries, namely encapsulated responsibilities. A properly architected se

I don't really care about service size. I care about service division across logical boundaries, namely encapsulated responsibilities. A properly architected service should be responsible for a particular domain, say payments, messaging, image processing, etc. It's up to each team to decide where to draw those lines. I think that for most teams, domain-specific services are superior to task-specific microservices, since it strikes the best balance between the benefits of separate services and the infrastructural overhead required to run a distributed system. That said I agree that you should start with a monolith.