I am planning to use the Microservices architecture for the implementation of our website. I wanted to know if it is right to share databases between services or if it is preferable to have a separate database for each service. In this regard, can I consider having one common database for all services or does it violate the very essence of Microservice architecture ?
Different services have different data storage requirements. For some services, a relational database is the best choice. Other services might need a NoSQL database such as MongoDB, which is good at storing complex, unstructured data, or Neo4J, which is designed to efficiently store and query graph data.
You do not need to provision a database server for each service. For example, if you are using a relational database then the options are: Private-tables-per-service – each service owns a set of tables that must only be accessed by that service.
Relational databases You'll have to start building microservices with what you have – a relational database, such as DB2, MS SQL Server, MySQL, PostgreSQL, and gradually split it into several small services. On top of that, you can use a relational database in microservices if you apply polyglot persistence.
As we mentioned earlier, each microservice can only access directly its own data store. Therefore, services need a communication method to exchange data. So, each service must provide a clear API. Consequently, there is a need for a failure protection mechanism in case the communication fails.
Microservices offers decoupling. You must break down your application into independent domains. Each domain can have a DB. In case other MS needs to access data owned by some other microservices, they have to communicate over the network.
In case you feel that there are too many dependent services and the network calls would be too much, then you can define a domain, clustering the dependent services together.
For instance -- Suppose I have an online Test evaluation Service where a manager of a company can post tests and he can view results of all the employees in his department.
My Microservices for this scenario would be:
Initial Design
After breaking it down, seems like employee, Organization and Department service would be making too much network/API calls as they are tightly dependent on each other. So it's better to cluster them.
Updated design
Each service could have it's own DB and it's independently deployable. User and Test Service can use mongoDB or any NoSql DB and Organization service can use RDBMS.
Hope this helps.
If you share the same database then you loose two of the most important advantages of microservices: strong cohesion and loose coupling (page 25).
You can share the same database if you don't share the tables in it. For example, microservice1
uses table1_1
and table_1_2
and microservice2
uses table2_1
and table2_2
. When I say uses I mean read and write. One microservice don't read and don't write on the other's tables.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With