In a microservices software architecture, 90% of the problems relate to data management between services.
In this post we see the summary of one of the design patterns that concern these issues: the database for service design pattern.
In the database for service design pattern:
- Each microservice has its own database, if it needs a database.
- Each microservice must never be able to directly access the database of another microservice.
Thanks to this design pattern:
- Each microservice can run completely independently from the other microservices.
- Each database can change schema/structure unexpectedly.
- Each microservice can make use of the type of database that will make it more efficient. (SQL VS NoSQL).
If we had a database used by multiple microservices, a database problem would affect all the microservices involved.
A database per service avoids introducing dependencies between microservices and is easier to modify, to scale and to implement with the most appropriate type of database.
But what happens if we develop a new microservice that must make use of the information present in the databases of the other services?
As we will see in the next posts, there are several solutions that can consider synchronous communication strategies between microservices or asynchronous, to events through an event bus.
To learn more about the topic of microservices architecture you can also check out this website microservices.io or this course to which this post is inspired: Microservices with Node JS and React.