0

Some background: We have similar entity stored in different databases because historically the entity used to come from different vendors(and it still does) and we stored it in three different databases. All the DBs have SP written over them which returns the entities based on few filter.Table schema of result set returned by all SP is same. UI doesn't know and care about where the entity is stored and where it is fetched from. So currently we call SPs on different DB,Bind the result set table to entities,Apply some business logic,Sort,Group and Aggregate entities in C# service based on service request.

Question: We are refactoring other part of application and For this service, Senior team member and manager think we should change each DB call to a microservice, with the reasoning that no one should be able to access the entity in given DB without connecting to microservice written over that DB(making a common gateway for that entity on given database) and said we should follow Database per service pattern.

I agrees with all the reason given for database per service architecture but no one external consumer going to consume our micorservice without all business logic, hence we are writing microservice to just bind data set to entities where we are sacrificing the performance by making an IPC call over the network. The other reason which I can think of is scalability as we can spin more containers of micro-services when load increases but we can also scale our current "monolithic" service in same way which makes direct async DB calls.

Can some please tell me some reasons(or guide me to some article which has same information) why we should create entity binding micro-services rather than direct SP? why we should sacrifice performance of service in the name of micro-service architecture? Or making Direct SP call is good in our case.

I appreciate your invested time in this question

Improve this question

1 Answer 1

Reset to default
1

Senior team member and manager think we should change each DB call to a microservice, with the reasoning that no one should be able to access the entity in given DB without connecting to microservice written over that DB(making a common gateway for that entity on given database) and said we should follow Database per service pattern.

I think your senior team member and manager have the Database per service pattern backwards.

That pattern states that each service (which offers some functionality to the system) should have their own persistent storage that is not intermingled with the storage of other services, not that a service can only access a single database.

From what you describe, you have an entity that is stored in different databases, depending on the vendor. It makes perfect sense to abstract that knowledge away behind a microservice API, but that particular microservice would have to have knowledge of the various databases that can contain this entity and how to read/update/etc. those entities. As long as nothing else is trying to get this entity directly out of the database, bypassing the microservice, the Database Per Service pattern is still upheld.

Improve this answer
2
  • Thanks for answer, do you think our current service which call 3 different database and which do aggregation, sorting and grouping also qualifies as Microservice, according to your answer we shouldn't break it in three different service, is that correct?
    – A.Learn
    May 3, 2020 at 15:42
  • @A.Learn, yes your current service would already qualify as a microservice in my book. Think of it this way: If the request load becomes too high for a single machine to handle, would it make sense to add a second machine so both machines do the grouping, but only the initial machine does also the other stuff? Or would it make more sense to let both machines do all parts you listed? Separate microservices should be able to scale independently.
    – Bart van Ingen Schenau
    May 3, 2020 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.