I have done quite a bit of reading about microservices but I have so far never designed any. I am working on doing that now and I am wondering which approach is correct (see the image below).
Basically, I've read that each microservice should own its data and only expose it via an API and that totally makes sense. However, that doesn't in itself say how specialized should microservices be. When breaking down a monolith, where does one stop? My intuition is that many online examples go too far.
In particular, breaking down into separate microservices relations that are tightly logically and functionally coupled, like
Users/Posts/Comments, while possible, just feels very wrong to me from architectural standpoint. This data is and is meant to be interdependent, why try to force it apart? Am I missing something?
Apart from data ownership and cohabitation, another conundrum I have is about the proper mapping between microservices and endpoints. If the way to access microservices is chosen to be via a RESTful API, does it have to be one microservice per endpoint or can one microservice have several endpoints? What's the best practice? Could I have one microservice with three endpoints and one database serving all three?
Does a microservice have a subdivision, and if so what is it called? A method? This is related to the previous question. If one microservice can do several things, how are things doing those things called?