Building microservice is not an easy job in terms of transaction consistency and isolation as data ownership is decentralized. Let's explore the

Transactions in microservices

submited by
Style Pass
2021-06-21 06:30:09

Building microservice is not an easy job in terms of transaction consistency and isolation as data ownership is decentralized. Let's explore the best practices for complex transaction coordination across multiple services.

Let's imagine that the user performs an action which on backend side t riggers calls to multiple service and the result is aggregated and returned to the user. From the user perspective this is an atomic action, but each service is doing some part of the job in order to fulfill user's request. During execution of user action some of the service might fail to do the job, which leaves system in inconsistent state and you can't leave it like this.

The first approach which one can think of is to use two-phase commit. In this approach transaction manager is used to split operation across multiple resources into two phases: prepare and commit.

In theory, this is great, unfortunately in practice it's not that great. First, this approach implies synchronous execution where if the resource is unavailable, the transaction cannot be committed and must roll back. This increases number of retries and decreases availability of the system (overall). Also, a distributed transaction acquires a lock on the resource under transaction to ensure isolation, which increases the risk of deadlocks for long-running operations.

Leave a Comment