DB design for microservice architecture [closed]

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.

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.