Best practices for microserviced applications

Question

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?

Answer 1

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

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.

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 terminate the TLS/SSL) and delegating the calls (via HTTP REST call or some RPC calls) to other services. It also prevents further pollution 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.

Answer 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.

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.