Database per Service Pattern

The problem that the Database per Service pattern addresses is how to define the database architecture, that is, how the data of a system with a microservices architecture are persisted. Initially, one approach might be to use a single database shared by all microservices. However, this contradicts the principle of independence and decoupling of microservices.

The second approach, related to the application of the Database per Service pattern, involves defining a private database for each microservice. In this case, the database becomes a component of the microservice, as no other microservice can directly access it, only through the API it exposes.

It is important to note that applying this pattern does not necessarily require a database server for each microservice, as there are different ways to ensure private persistent data, such as:

  • Private tables per microservice (in relational databases)
  • Schema per microservice
  • Database server per microservice

Implementing private tables or schemas per microservice shares some advantages, such as better resource utilization and reduced overhead.

On the other hand, the disadvantages include not allowing for better adaptation of resources and database technologies to the requirements of the microservices. Additionally, these two approaches add complexity and coordination necessary to ensure that the boundaries of the microservices are not breached. That is, there should be no database interaction between private data of different microservices.

Implementing a database server per microservice becomes the most viable option as it allows for choosing the best technology according to the requirements of the microservices. Another advantage is the absence of response capacity sharing with other microservices' databases. Similarly, it is possible to apply specific quality attributes individually to each microservice's database server, such as scalability, resilience, availability, among others. Lastly, it ensures decoupling and independence, as changes in one microservice's database will not impact others.

On the downside, the associated disadvantages include the need for more resources and increased complexity, as it becomes necessary to maintain, control, and deploy more components for the architecture.


References

Dissertation: "Study on the importance of the Principles and Patterns of Microservices Architectures", 2023
Website: "Microservice Architecture"