CODEWITHSUNDEEP
microservicessoftware-designn-tier-architecture
vishal savsani
vishal savsani

Reputation: 399

Separate microservice for database access

I'm managing a very large enterprise application in that I've implemented microservice architecture. Standalone microservices have been created based on business entities & operations. For example,

  1. User Operations Service
  2. Product Operations Service
  3. Finance Operations Service

Please note that each service implemented using an n-tier architecture with WCF. i.e have separate tiers(which is independently deployable to separate server) for business and data access.

There is a centralized database which is accessed by all the microservices. There are a couple of common entities like 'user' accessed by all the services, so we have redundant database calls in multiple services. More efforts required due to database access from many places(i.e a column rename requires deployment of all the apps)

To reduce & optimize code, I'm planning to create separate microservice and move all the database operations into it. i.e services can call "Database Operations Service" for any database operations like add/update/select.

I want to know if there are any hidden challenges that I'm not aware of. Whether should I go with this thought? What can I consider as improvements in this concept?

Upvotes: 1

Views: 1435

Answers (1)

cassandrad
cassandrad

Reputation: 3536

I'm planning to create separate microservice and move all the database operations into it

That's how you will lose all benefits from microservice architecture. One service is down — the whole application is down. Unless you have replication on several nodes.

If your app does not work if one service went down(not implying that it's that service that connects to database), then it's still bad architecture and you are not using benefits of microservice architecture.

Correct for of communication would be if service would have their own databases. Or at least that every service that wants, for example, entity User, will not fetch it from DB, but will fetch it from appropriate service. And that appropriate service could fetch it from common DB at the beginning.

Next step (improvement) in the process of accommodation to microservice architecture would be creation of separate databases for each service. And by “separate” I mean that temporal fault of one service or temporal fault of one database will allow the rest of the app to be alive and functioning.

Generally, there are no hidden challenges in your approach. It just does not give any benefits, as an intermediate form between monolith application and microservice-based.

Upvotes: 1

Related Questions