In this tutorial, we are going to learn about Choreography Pattern in detail.

Choreography Pattern

• If something goes wrong in one microservice, it has to notify the up-stream or previous microservices to roll back the transaction.

In this example, we have OrderMicroservice and CustomerMicroservice.

• OderMicroservice creates an order and manages the transaction in the traditional way within the database, and once it is done.
• It raises an event called order created between these microservices there will be an event streaming platform such as Apache Kafka.
• So once the order is created event is raised, CustomerMicroservice is subscribed to that event streaming platform and receives that order created event and tries to create a new transaction in its own database,
• Update the fund or balance of the customer and then finishes the operation.

Choreography Pattern Failure Scenario

If something goes wrong in the Choreography Pattern.

• OrderMicroservice creates the order, raises the order and create an event.
• CustomerMicroservice receives that event and tries to update the funds, but if something goes wrong, like customer doesn’t have enough funds or credit card doesn’t work. Due to this, transaction cannot be committed successfully.
• In this case, customerMicroservice has to notify upstream microservice i.e., OrderMicroservice about the failure, and it has to handle the use case either by removing the record from the database or roll back the changes made.
• In Choreography Pattern, you can see that there is no Orchestrator in between these two microservices.
• The logic of managing the transaction is scattered across all the engaged microservices.