January 24, 2021 at 5:37 am
Hi Experts,
Our architecture team come up with a new plan to have multiple databases for different microservices , that means for each project we will have a minimum of 3 databases only for the application, one for user management and another one for documents. As per them this is to make sure exclusive access for each microservice data. DB Team suggested to use different schema inside the same DB to ensure this and to reduce the dependency of multiple database from recovery point of view.
Kindly advise whether the 3 database option is optimal or to go with one database?
January 24, 2021 at 11:42 am
Having a single database for all of the applications sounds like a bad idea – what if one app has to be restored but the others don't?
One DB per app sounds more reasonable. What is the rationale behind having multiple databases per app, rather than just one?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
January 24, 2021 at 11:47 am
Also, 'User Management' potentially sounds like something which should be handled by a single database.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
January 25, 2021 at 4:52 pm
I don't love the microservices model for lots of database stuff. You lose the power of the database to combine data together. If it is truly separate and isn't aggregated, then fine, but otherwise, many of the big microservices places (like Uber), suck all this data into a DW, often a relational db, to combine and report on data.
That being said, do you need synchronization of the data? Are you assuming your microservices somehow have the data in sync? If you recovered the data for application and documents at different times, is there an issue here?If there is, use 1 db and schemas. If not, separate ones work.
You have to really think about the data model and consistency here. I would look at how the services work if one of the dbs is down. If you're really down, then you aren't really working with microservices per se, you would end up with splitting the app, but unable to us it if something breaks.
From the scalability standpoint, you can get a really large database server to handle a load, so from that standpoint, I might plan for 3 instances, each with their own db. That gives you a future plan. However, if you set up the services well, going from 3 schemas to 3 dbs to 3 instances shouldn't be hard.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply