'Microservice architecture Database rollback

I am having a microserice architecture with multiple services, each containing their own Database, and a Gateway which is considered as the business logic.

Gateway:

  • Handles the logic
  • Calls the services

Service 1:

  • Stores service related data
  • Has it's own database

Service 2:

  • Stores service related data
  • Has it's own database

So for example Gateway calls Service 1 to insert some data. Then it calls Service 2 to also insert some data.

Now the problem: What if the call to Service 2 fails, how do I undo the insert to service 1? I know I could call a http://.../delete method, but this cannot be the best solution. So what is the best way to undo the changes?

c++sharpasp.netasp.net-coremicroservices


Solution 1:[1]

Considering very specific details of your architecture, a straight forward answer would be distributed transaction management. But that would be a bit difficult not in terms implementation but later in terms of maintenance, performance etc.

But my question, is I feel there is some flaw in the architecture, because if you have to rollback the data in service 1 because of some failure in service 2 then there is a tight coupling between these 2 services and this not something how a microservice should behave like as it is supposed to be independent. So , you may have to change a architecture a bit

  • You may share the database between microservices which will make transaction handling easier.
  • You may introduce a communication mechanism between microservices such as Apache kafka (RabbitMQ or Hazelcast are cost effective).

Solution 2:[2]

I have encounter such a problem also, and I write a project for handling distributed transactions, which is quite easy to use.

https://github.com/dtm-labs/dtm

You can write some codes like this:

  saga := dtmcli.NewSaga(DtmServer, shortuuid.New()).
    Add(qsBusi+"/TransOut", qsBusi+"/TransOutCom", req).
    Add(qsBusi+"/TransIn", qsBusi+"/TransInCom", req)
  err := saga.Submit()

The transaction manager DTM will call TransOut and TransIn. If all succeed, the distributed transaction succeed; if any service failed, the compensate services is called to ensure the data consistency.

Also DTM provide automatic retries, idempotent data modifications to help developers handling temporal failure.

DTM has become a popular distributed transaction solution.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 CovetousSlope
Solution 2

Related Questions