If you use domain-driven design, then microservices boundaries can be naturally drawn at domain boundaries and that will tend to work out pretty well. They should be as big as they need to be to support the domain.

I've definitely seen systems where the general gist was a microservice per data type, without any consideration of how those data types and the overarching domain were organized. And it turned out pretty terrible -- UI calls that were very coherent from a domain perspective blowing up into a chain of 3 or 4 calls to other services to get all the required data.

In reality, there was a primary data type with a few different types of supporting data. So a single microservice serving that primary data type along with the supporting data would have been quite appropriate.