Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

DB design for microservice architecture [closed]

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 ?

like image 238
user2288991 Avatar asked Apr 15 '17 13:04

user2288991


People also ask

What is the best DB for microservices?

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.

Can microservice exist without database?

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.

Which database is used in microservices?

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.

How do microservices communicate with databases?

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.


2 Answers

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

  1. User Service: For login and user information.
  2. Test Service: Service to evaluate tests.
  3. Employee: Handles employee details
  4. Company: Handles organization CRUD
  5. Department: Handles department CRUD

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

  1. User Service : For login and user information.
  2. Test Service : Service to evaluate tests
  3. Organization : Handles Company, Employee and Department related operations.

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.

like image 177
Nitish Bhardwaj Avatar answered Oct 25 '22 05:10

Nitish Bhardwaj


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.

like image 32
Constantin Galbenu Avatar answered Oct 25 '22 04:10

Constantin Galbenu