Best practices for microserviced applications [closed]

Best practices for microserviced applications [closed]

I have a monolith application and I’m thinking of rewriting the application to move towards a microserviced architecture, however there are a few things I’m struggling to understand.
Does a microservice need to have their own web api? I was thinking to just have a single api gateway and then reference class libraries. However noticed a lot of examples have a web api gateway and then also have web api’s for different services which i dont understand why?
My database has a lot of referential constraints as a lot of tables reference one another which cannot be separated. Would the best practice be to have a common DB layer and dependency inject these into each service?

Solutions/Answers:

Solution 1:

This is a quite broad question and beyond an answer. I am going to provide you some directions and links for further details.

Does a microservice need to have their own web api? I was thinking to
just have a single api gateway and then reference class libraries.
However noticed a lot of examples have a web api gateway and then also
have web api’s for different services which i dont understand why?

This is called API gateway pattern. Please check the link provided to get an idea for why and what are the advantages. This is very common in microservices architecture.

My database has a lot of referential constraints as a lot of tables
reference one another which cannot be separated. Would the best
practice be to have a common DB layer and dependency inject these into
each service?

Depends. If you can’t split the data management layer into different vertical slices, you can share the same database for all services.

Related:  Zuul not passing the Content-Type to the service

Data management in microservices architecture can be many forms:

  • Database per Service
  • Shared database
  • Saga (Choreography and Orchestration)
  • API Composition
  • CQRS
  • Event sourcing
  • Application events

You can check shared database pattern.

Update

Having an API gateway how do people tend to design their application?
Do they have class libraries which they just reference from the api
gateway, isn’t that defeating the idea of a “microservice”?

API gateway is an independent microservice which is public facing and handles all the request/response from clients. It’s a thin layer which is responsible for client authentication (providing authentication token against client’s credentials, certificate verification etc) and delegating the calls (via HTTP REST call or some RPC calls) to other services. It also prevents further propagation of erroneous API calls by failing fast on gateway layer. Other services are not class libraries or any kind of static dependencies here. They are separate independent microservices.

Solution 2:

The primary benefit of microservice architecture is that each microservice are loosely coupled. This loose coupling is possible because each microservice can maintain its own interfaces (be it through Web API or others) and state (be it through persistent databases or other means).

I am not sure I understood your example correctly, but it sounds like you are planning to have a single API interface that references multiple class libraries from different “microservices”. In this case, the coupling between the API interface and the class libraries would prevent you from making independent changes in either the API interface or the class libraries. Hence you would often see implementations that have their own separate Web APIs.

Related:  Kong Request Transformer, dynamic value, taken from Redis

As for your database design, I recommend the Database per service pattern. Sharing databases across different services is considered as an anti-pattern since it would couple your services at the data layer.

References