Search code examples
microservicesdistributed-database

Distributed Database Design Architecture Use Case for Users & Authentication

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?

Solution

  • 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