Improving Microservices Reliability With Two-Phase Commit

DZone 's Guide to

Improving Microservices Reliability With Two-Phase Commit

An article that discusses how we can improve reliability between microservices — focusing on the Two-Phase-Commit technique.

· Microservices Zone ·
Free Resource


Make your microservices reliable.

Hi everyone! Today I would like to talk a bit about how we can improve reliability between microservices. This is the first article of a series and we'll be focusing on the Two-Phase-Commit technique.

Let's suppose you're working on a microservices architecture and you need to have them talk to each other in some way. An isolated service is not that useful, we have to share some data with the rest of our system. Maybe you're working on the next Amazon or Netflix, who knows!

You may also like: Distributed Transactions With the 2PC Protocol

amazon vs. netflix
Let's make a simple example. Imagine a user placing an order on an eCommerce. The Orders microservice receives the command, stores the data in its persistence layer and then needs to inform all the interested parties. For example, a notifications service that will send emails to the customer and the admins.

Of course, we don't want emails to be sent if the Orders microservice fails to process the command.

One possible approach is the famous Two-Phase-Commit (aka 2PC):  

As you can easily guess, it's a two-step process:
  1.  The Coordinator service asks all the participants if they are ready to commit the transaction. They can reply with a yes or no. Note that if a single service replies with a no ( or a timeout or any other error), the full transaction is automatically canceled. 
  2. If all the participants have answered yes, the Coordinator sends the Commit command to them and waits for the final ack.

Although functional, there are few drawbacks to this approach. First of all, it comes with an intrinsic performance penalty as we're putting all the actors on hold multiple times waiting for an answer.

Secondly, in some cases, it may be possible that other transactions triggered in between are paused until the whole process completes.

If the Coordinator fails for some reason at the beginning of Phase 2, all the other services are left hanging in a limbo-state.

Don't get me wrong, 2PC is a good approach, but like all the other tools in our belt, we need to know when we can be used. For example, it's extremely useful when replicating data among a cluster of DB replica nodes.

So, going back to our eCommerce microservices, in another article we'll see how can we can leverage the Outbox Pattern to safely notify our services when an order has been placed. 


Further Reading

Apache Ignite Transactions Architecture: 2-Phase Commit Protocol

Microservices and Distributed Transactions

Distributed Transactions and Microservices Still Don't Mix

microservice communication ,software architecture ,design patterns ,microservices ,two-phase-commit

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}