[creatorbytes]

This sounds like a microservice vs monolith statement in disguise.

Respectfully I disagree, maybe with more context I’d be on a similar boat.

The communication overhead is a real challenge to be reckoned with. I don’t think the mere fact something has 10 functions in one service makes it better or worse than breaking those out into their own services (not even getting into at what level do you break them down? Since most all code is a composition of functions)

Personally I go monolith first, then if and only if there’s a function of the monolith that needs to scale separately from the rest of its parts, then I’ll consider making it its own service (and this has to be a pretty large extreme to take on this burden)

Too many times I’ve been burnt by attempts at micro services, which seem to stagnate faster than monoliths at some companies. I also think there’s a higher degree of documentation each new service made, vs keeping it an endpoint in a monolith. But I digress

[Izkata]

There's an in-between point that I think is more common than good microservices, that I think you're describing, that I've seen called a "distributed monolith". Basically what happens when the microservices are too intertwined to be independently replaceable as GP suggests.