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.

Leave a Comment