Transactions in microservices

Question

I have read some articles about microservices architecture, but no one takes the topic of transaction. All that they says that this is hard to do it. Maybe someone can describe how to handle this?

But not from domain side, but from technology side. Lets say that we have business case where we need to invoke two different services and both of them make some changes on database. But how to rollback if some error occurs on the second one?

Who knows some libraries or design patter for this problem?

Answer 1

I may not be the ultimate expert in this, but I'm sure you're heading towards the Distributed Transactions . In order to have them running, all the application service components need a common shared transaction id, and you have to make sure that every component is informed about the state of the transaction. It is asynchronous, so you'll require substantial prog skills.

Here are distributed transactions mentioned or discussed:

https://en.wikipedia.org/wiki/Distributed_transaction

http://contino.co.uk/microservices-not-a-free-lunch/

http://martinfowler.com/articles/microservices.html

It would seem people try to avoid it as it is difficult. Maybe that's why you don't find much about.

Hope this helps a step forward :-)

Answer 2

The best design is having isolated services: each service just do its work within its own transaction and your workflow expects failures on the single service.

If you really need to commit only if all the services are called without errors you should create an higher level service that perform those calls inside an external transaction.

Answer 3

The first raw thing which came to my mind after reading this question is to create every add api with a delete api with ,lets say, an extra boolean flag delFlag.

boolean flag delFlag;

For POST, it will be 0. For DELETE, it will be 1.

Now you maintain a Transaction Manager which is a super service to all your micro services. In this service maintain the calling queue of all the services and the APIs. As and when a service fails, get the calling api and call the delete method of that service and undone whatever u have done.

PS- Just a raw thought. Correct me if you think it is wrong.

Answer 4

Building on top of previous answers, distributed transactions are the solution. In my opinion you don't want to build your own mechanisms for tracking global transactional state, rather you want to use some kind of product - there are several out there. I have written a lengthy blog article about solving this issue with a Java application server:

http://blog.maxant.co.uk/pebble/2015/08/04/1438716480000.html

Answer 5

两阶段提交可以是option.Coordinator发送提交请求消息给cohorts.Cohorts发回ok.After协调器发送提交消息到同类群组。如果任何故障happpens协调器发送回滚消息给同类群组。

Answer 6

You can use a workflow engine(like JBPM,Activiti) to orchestrate the logic and handle transaction failures or compensatory transactions in it to achieve data integrity. This is the similar case you use in SOA architecture with ESB,BPMN and Web services