We are to design a microservice architecture based project having multiple relational schemas (i.e all tables are somehow connected to each other)
Is it better to use separate databases for each service
Or to have a common sharable DB with multiple replicas?
- User Service
- KYC/KYB service
- Socket Service
- Notification service
- Payment Service
I trying with single DB
This is a very broad question and there are many opinions on the topic. I would advise against having a shared database for your microservices. Every microservice should have its own database and be deployable independently. If microservices share the same database schema that means they are coupled and can't be deployed independently, which you want to avoid. Also, multiple microservices can make a similar database schema change which will result in a conflict and a total mess. Each microservice might have a need for a different type of database, e.g. one might need relational, the other might need NoSQL, and the third might need a Graph database so having a shared database might not make sense from the functional perspective either.
The challenge when having separate databases is how to keep them in sync. The answer is to have a message broker between them that will send messages between microservices in order to sync data. The data will eventually be consistent. This complicates the architecture significantly and it is justified only if the complexity is big. I would advise starting with the modularized monolith and then splitting later when the app becomes big enough to justify the architectural complexity.
This is a great read on the topic https://www.nginx.com/blog/event-driven-data-management-microservices/ by Chris Richardson, one of the authorities on the topic.