Which of these microservice designs is correct?

Question

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 Customers/Accounts/AccountTransactions or 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?

Answer 1

The microservice architecture doesn't force you to separate things that belong to each other:

• Microservices should correspond to an independently deployable service. So if you would cut into parts things that really belong together, their independence would be purely hypothetical.
• This being said, a critical review of existing coupling is necessary because sometimes we tie together things that could be designed in a decoupled way as well.
• Chris Richardson, a pioneer of microservices, proposes 4 decoupling strategies: by business capability, by subdomain, by self contained service (that's the smallest), and by team. At least 3 of these would package your two functions together. The 4th probably as well, depending on the outcome of your critical review.

Now endpoints are is a different story. You could, of course, expose each of your microservice to the external world. However, there are far more advantages and flexibility by hiding it behind a kind of facade called API gateway through which the outside world is channeled. This decouples your microservice view, where you might want to add, remove, move functionality, from the front-end world that would still see one unified interface.

Answer 2

The point of microservices is to get independent pieces of software. This independence serves multiple purposes like maintainability, organizational fit, scalability, etc., which you might find advantageous in your context.

Splitting into services based on data, while seem to be popular, is rarely if ever a good choice for microservices. The simple reason being, that it won't result in independent pieces.

The only way to arrive at an independent piece is to split vertically. I.e. put everything in a service that is needed for a specific case. Request-response based communication among services should be minimized, ideally completely eliminated.

Ideally this also means the services should bring their own UI! Again, this is the only way you guarantee independence and can give full control over to the team maintaining the service. If the UI is a separate thing, you already introduce a hard coupling between components, teams, release schedules, etc.

So I would say none, then again, there might be special circumstances where you might go for either of those designs.

Answer 3

Yellow seems like a monolith.

Red is division of microservices via functionality, which could be better mapped to a monolith.

Blue and green seems more valid, as they are separated via business entities.

Now,

a) you can try using a Gateway, as previous stated. This will simplify matters for you.

b) expose as many endpoint as you wish. This does not violates any principle . The goal here is to achieve high cohesion and loose coupling, meaning that related functionalities sit together.

c) The purpose of microservices is that you can deploy them independently, therefore less cost to configuration management (change requests, new functionalities etc)(software evolution).

There is also this pattern which provides some reasoning on why each microservice should have its own database.