Databse design in Microservices

Question

I am planning to move one monolith ASP.Net MVC application to micro-service architecture.

The application is on Educational domain ,and bellow are sub modules currently has,

System Admin

Institute Admin

Candidate/Student Portal

Facilitator/Teacher Portal

Course Setup (this can be done by Facilitator or Institute Admin)

Exam Portal

Reporting Portal [NEW]

Video Conf Portal [NEW]

To achieve micro-service architecture ,I break the current system like the diagram below ,and Create DB for each module.

Here I face a problem ,say for Exam Db currently there are some relation with Course and Subject etc..

and the Course and Subject related table moved to another DB , then how do I maintain the relation and data in Exam DB ?

Should I create a replica of the Course and Subject table inside Exam DB and populate them when new data is inserted in the original db (with event Que) ?

Or is there any other technique to achieve this with minimal change and effort.

Also how I maintain transactions between different DBs .

Answer 1

Database per service

• Using a database per service has the following benefits:

Helps ensure that the services are loosely coupled. Changes to one service’s database does not impact any other services.

Each service can use the type of database that is best suited to its needs. For example, a service that does text searches could use ElasticSearch. A service that manipulates a social graph could use Neo4j.

• Using a database per service has the following drawbacks:

Implementing business transactions that span multiple services is not straightforward. Distributed transactions are best avoided because of the CAP theorem. Moreover, many modern (NoSQL) databases don’t support them.

Implementing queries that join data that is now in multiple databases is challenging.

The complexity of managing multiple SQL and NoSQL databases

• There are various patterns/solutions for implementing transactions and queries that span services:

• Implementing transactions that span services:

use the Saga pattern.

• Implementing queries that span services:

API Composition - the application performs the join rather than the database. For example, a service (or the API gateway) could retrieve a customer and their orders by first retrieving the customer from the customer service and then querying the order service to return the customer’s most recent orders.

Command Query Responsibility Segregation (CQRS) - maintain one or more materialized views that contain data from multiple services. The views are kept by services that subscribe to events that each services publishes when it updates its data. For example, the online store could implement a query that finds customers in a particular region and their recent orders by maintaining a view that joins customers and orders. The view is updated by a service that subscribes to customer and order events.

Read more here

Shared database

• The benefits of this pattern are:

A developer uses familiar and straightforward ACID transactions to enforce data consistency

A single database is simpler to operate

• The drawbacks of this pattern are:

Development time coupling - a developer working on, for example, the OrderService will need to coordinate schema changes with the developers of other services that access the same tables. This coupling and additional coordination will slow down development.

Runtime coupling - because all services access the same database they can potentially interfere with one another. For example, if long-running CustomerService transaction holds a lock on the ORDER table then the OrderService will be blocked.

A single database might not satisfy the data storage and access requirements of all services.

Read more here

Additional must reads: CQRS & API Composition