CODEWITHSUNDEEP
microservices
user2439203
user2439203

Reputation: 35

One database per API or shared database for multiple APIs in Microservice

I started reading microservices architecture and got confused with one below point.

Each service should have a separate database.

Does each service mean a single web(rest) api having its own database?

For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.

Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc. Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db

What is correct ? All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?

Thanks.

Upvotes: 0

Views: 3598

Answers (2)

Radek
Radek

Reputation: 515

you can have common database for all microservices, it is one of the microservices patterns:

https://microservices.io/patterns/data/shared-database.html

https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html

check those links to see advantages and disadvantages of this approach.

Upvotes: 1

justincely
justincely

Reputation: 1070

To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.

One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.

Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.

Upvotes: 2

Related Questions