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