How Choreography-based Saga Works in Microservices

In this article we would explain how a Choreography-based Saga works in microservices. Then present a simple algorithm.

In Choreograph-based saga approach, each local transaction emits domain events. This events then triggers local transaction in other services subscribed to these events.

So assuming there are three services A, B and C. When a local transaction occurs in A, it publishes an event that triggers a local transaction in B. Then B executes a local transaction an also publishes event. This event published by B triggers a transaction in C.

You can now see that in choreography, there is no need for some central system to coordinate the communication. All the services communicate among themselves.

This is illustrated in the Figure 1 below:

How it Works

Let’s take an online store for example. We have two services:

Order Service: responsible for handling orders

Customer Service: responsible for maintaining customer records

In this case, a choreography-based saga would have the following steps:

1. The Order Service creates a new order. It sets the state to pending
2. The Order Service publishes an Order Created event
3. The Customer Service receives this event
4. The Customer Service attempts to reserve credit for this order
5. If the credit was reserved successfully, then the Customer Service published a Credit Reserved event
   • This event is received by the Order Service
   • The Order Service sets the state of the order to approved
6. If the credit was not sufficient, then the Customer Service publishes a Credit Limit Exceeded event
   • This event is received by the Order Service
   • The Order Service sets the state of the order to approved

Choreography-based Saga Algorithm in Detail

Now let’s try to determine the time between when the saga starts and ends. Take a look at Figure 2. We would just use generic names for the services: MS1 and MS2. We also assume that the events pass through a service discovery gateway. We also assume the MS1 and MS2 are associated with databases DB1 and DB2.

The steps would be as follows:

Step 1: External event fires a method is MS1 that  changes the state attribute of C1 from S1 to S2. (This could be a client app)

Step 2: DB1 saves the time T1 of the change in the TimeStamp attribute of C1

Step 3: Once the updates is complete, MS1 fires an event called MS1_state_change_success()

Step 4: MS1 calls a method change_state_to_S2() on MS2

Step 5: MS2 executes a logic on DB2 that changes the state attribute of collection C2 from S1 to S2

Step 6: The logic fails

Step 7: MS2 fires an event called MS2_state_change_failure()

Step 8: The MS2_state_change_failure() event rolls back the transaction on MS2

Step 9: Once the rollback is complete, MS2 fires and event called change_state_to_S1() on MS1

Step 10: MS1 executes a logic on DB1 that rolls back the state of C1 from S2 to S1

Step 11: The new Timestamp is also recorded as T2

Step 12: Difference between T1 and T2 is recorded as time taken to complete the choreography

Benefits and Limitations of Choreography-based Saga

Some research(by Chaitanya K. Rudrabhatla) shows that event choreography has a better performance than orchestration. However, as the number of service increases, the implementation becomes very complex since there is the need to handle multiple events.