Design problem in Microservice architecture

In my company we are using microservices but till now we were not following microservice principles. so in architect review we have been told to replace the same.

We have one service called CommonService,so any request comes by client hits this service. This request hits the database and create the record and then forward the request to ManagementService. Management Service access the same DB and table and update the record created by CommonService.(Here Common and Management Both API hitting the same table in database.)
same we have for other 2 services.

Common-->DB(Common_MGMT)--Management-->DB(Common_MGMT)
Common-->DB(Common_Sales)--Sales-->DB(Common_Sales)
Common-->DB--HR-->DB 

So Common_MGMT table hit by first 2 service, Common_Sales table hit by Common and Sales API ,same for third.
A particular customer will access only one service where it is Management , Sales or HR but he will come through commonservice.

Now We have to follow microservice principle and due to management reasons we can not follow Database as a service and also we don't have option to redesign from scratch.

So we have thought to introduce one DBservice which will hit the database,so that it is like when new request will come to Commonservice then it will access DBservice through REST and DB service will create record in database. Then Management Service will access DBservice and DBService will update the same record in database. likewise for sales service and HR service.

Now still I am using same table in Database but this time only DBservice accessing. AM I following the microservice principle here?

1. Here which approach will be better Private table per service or Schema as a service? or both will work and I can use either of them?

2. There will be huge latency in this approach, can the solution be improved?

3. If DBService will fail then it will be single point of failure? can we do something other than creating multiple instances?

Overall can you suggest the solution for original problem? Is the solution we are proposing correct or is there better option?

Any other suggestion most welcome.

The solution to your problem is not simple and straightforward, because there are many parameters involved while breaking a service into microservices. From what I see, you are having multiple services which are communicating with each other frequently but still are having different code bases and on top of that they do access the same database (I am assuming the same schema when you say the same database). Now when you say that you can not do it from scratch then there are very few possible solutions to this problem

1. Instead of updating and hitting the DB every time for the calls in the initial service, why don't you just pass the information to downstream services and let that service do the update if possible (this is still not an ideal solution but it reduces the latency by reducing one DB call)

Common-->Pass-Data--Management-->DB(Common_MGMT)
Common-->Pass-Data--Sales-->DB(Common_Sales)
Common-->Pass-Data--HR-->DB

2. Do the reverse, instead of landing your API call in Common, why don't you land your API calls in actual services first and then inject Common as a dependency in your services and let that part process other data? (this is still not from scratch but I believe will need considerable amount of work, but still better solution than 1).

Introducing a DBservice as an intermediary between microservices and the database can follow microservice principles.
However, there are aspects to consider.

Private table per service or schema as a service can both work, depending on specific needs. Coordination between services is necessary to avoid conflicts and ensure data consistency.
Using a single database for multiple microservices can cause performance issues.
Database-per-service approach can improve scalability, isolation, and data consistency.
Introducing a DBservice can affect performance due to additional network hops. Caching or optimizing database queries can reduce latency. A load balancer or replicated database cluster can ensure high availability.
Redesigning microservices architecture can improve scalability, and data consistency, and reduce contention.

Event-driven architectures and asynchronous messaging can decouple microservices and improve scalability and fault tolerance.
Containerization and orchestration technologies can simplify the deployment and management of microservices.

Actually considering your scenario specifically, I can think of two other possible solutions for you:

1. Either create Common service as a jar and import it into your Management, Sales, and HR service and use it from there only

2. Normalization of a table in such a way that Common Service and Management Service etc work on different tables. I am just thinking to divide a table into two parts

So below are the points to keep in mind.

• First, decide how are you segregating your functionalities into services.
• You can segregate based on domain, e.g. customer service, product service etc. Each of this service would have it's own db, and whenever another service needs to deal with anything in this DB, it will go through this microservice.
• You can then build usecase specific services on top of the domain specific services.
• It is really difficult to justify microservice architecture with your DB as a single point of failure.

Please refer to this website for more detailed information on microservices. Since you seem to be just getting started, this is a good starting point.
https://microservices.io/

One way to approach it would be to split the monolith in terms of functional modules with an interface and implementation and then move those modules into standalone services.

The idea is that if one functional module changes, others don't have to be validated as rigorously.

Update#1 -

1. If you want to improve your understanding try this link - https://microservices.io/

2. I have answered in a generic way (was trying to get within the bounty window but now it looks like there is a 1 day grace!). Never the less believe they still hold.

   If you have a single database and that is your primary concern (which makes sense) then backups are your only friend. So you can first think of a replication db before you start thinking about monolith vs microservices. It would be no fun to tell your customers you lost their data because the db server crashed.

   Additionally to improve speed, using RDBMS you can consider sharding concepts (where rows are distributed across multiple servers) in addition to replication. You should ideally be able to manage this within the scope of your definition of 'redesign-from-scratch' limitation.

Calling dbservice via rest api, won't it be like tight coupling and add latency? Can we not do this operation using messaging api? Such that even if dbservice goes down, message can still be processed, once it's up.