0

I am now trying to design database for my micro service-oriented application in a distributed way. My application is related with management of universities. I have different universities say A, B, C. Each university have separate users for using their business data. Now I am planning to design separate databases for separate universities for storing their user data. So each university has their own database for their users and additional one database for managing their application tables. If I have 2 universities, Then I have 2 user details DB and other 2 DB for application tables.

Here my confusion is that, when I am searching for database design, I only see the approach of keeping one common database for storing all users (Here for one DB for all users of all universities). So every user is mixed within one database.

If I am following separate database for each university, Is possible to support distributed DB architecture pattern and micro service oriented standard? Or Do I need to keep one DB for all users?

How can I find out which method is appropriate for microservice / Distributed database design pattern?

halfer
  • 19,824
  • 17
  • 99
  • 186
Mr.DevEng
  • 2,651
  • 14
  • 57
  • 115

2 Answers2

1

Actually there could be multiple solutions and not one solution is best, the best solution is the one which is appropriate for your product's requirements.

I think it would be a better idea to go with separate databases for each of your client (university) to keep the data always isolated even if somethings wrong happens. Also with time, the database could go so huge that it could cause problems to configure/manage separate backups, cleanups for individual clients etc.

Now with separate databases there comes a challenge for managing distributed transactions across databases as you don't know which part is going to fail among many. To manage that, you may have to implement message/event driven mechanism across all your micro-services and ensure consistency.

Regarding message/event mechanism, here is a simple use case scenario, suppose there are two services "A" (user-registration) and "B" (email-service)

  1. "A" registers a user temporarily and publishes an event of sending confirmation email.
  2. The message goes to message broker
  3. The message is received by "B".
  4. The confirmation email is sent to the user.
  5. The user confirms the email to "B"
  6. The "B" publishes event of user confirmation to the broker
  7. "A" receives the event of confirmation and the process is completed.

The above is the best case scenario, problems still can happen in between even with broker itself. You have to go deep into it if you think you need this.

Some links that may help.

http://how-to-implement-a-microservice-event-driven-architecture-with-spring-cloud-stre

A Guide to Transactions Across Microservices

ktk
  • 297
  • 4
  • 13
  • ok..Thank you for your response. Its great pleasure to me. Can you say why you said that "Message/event driven mechanism across all your micro-services" ? What I need to explore for doing that? – Mr.DevEng Mar 31 '18 at 06:38
  • no prob. From that i mean, keeping message brokers in place (e.g active mq) that would persist and ensure the message propagates to the receiver services even if there is something broken. Please see my extended another answer, as its too long for the comment here. – ktk Mar 31 '18 at 07:39
  • Ok . Thank you. – Mr.DevEng Mar 31 '18 at 09:07
0

I don't think that this is a valid design, using a database per client which is a Multi-tenant architecture practice, and database per microservice is a microservice architecture practice. you are mixing things up.

if you will use microservice architecture you better design it as Bounded contexts and each Context has its own database to achieve microservices main rule Autonomy

Binary
  • 112
  • 4