![\"\"](\"https:\/\/www.kindsonthegenius.com\/microservices\/wp-content\/uploads\/sites\/18\/2019\/11\/Choreography-Based-Saga-me.jpg\")
<\/a>How it Works<\/strong><\/h5>\nLet’s take an online store for example. We have two services:<\/p>\n
Order Service<\/em>: responsible for handling orders<\/p>\nCustomer Service:<\/em> responsible for maintaining customer records<\/p>\nIn this case, a choreography-based saga would have the following steps:<\/p>\n
\n- The Order Service creates a new order. It sets the state to pending<\/li>\n
- The Order Service publishes an Order Created event<\/li>\n
- The Customer Service receives this event<\/li>\n
- The Customer Service attempts to reserve credit for this order<\/li>\n
- If the credit was reserved successfully, then the Customer Service published a Credit Reserved event\n
\n- This event is received by the Order Service<\/li>\n
- The Order Service sets the state of the order to approved<\/li>\n<\/ul>\n<\/li>\n
- If the credit was not sufficient, then the Customer Service publishes a Credit Limit Exceeded event\n
\n- This event is received by the Order Service<\/li>\n
- The Order Service sets the state of the order to approved<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
<\/p>\n
Choreography-based Saga Algorithm in Detail<\/strong><\/h5>\nNow 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.<\/p>\n![\"\"](\"https:\/\/www.kindsonthegenius.com\/microservices\/wp-content\/uploads\/sites\/18\/2019\/11\/Choreography-Based-Saga-in-details.jpg\")
<\/a>Figure 2 – Choreography-Based Saga Analysis in details<\/figcaption><\/figure>\n <\/p>\n
The steps would be as follows:<\/strong><\/h5>\nStep 1<\/b>: External event fires a method is MS1 that\u00a0 changes the state attribute of C1 from S1 to S2. (This could be a client app)<\/p>\n
Step 2<\/b>: DB1 saves the time T1 of the change in the TimeStamp attribute of C1<\/p>\n
Step 3<\/b>: Once the updates is complete, MS1 fires an event called MS1_state_change_success()<\/b><\/p>\n
Step 4<\/b>: MS1 calls a method change_state_to_S2() <\/b>on MS2<\/p>\n
Step 5<\/b>: MS2 executes a logic on DB2 that changes the state attribute of collection C2 from S1 to S2<\/p>\n
Step 6<\/b>: The logic fails<\/p>\n
Step 7<\/b>: MS2 fires an event called MS2_state_change_failure()<\/b><\/p>\n
Step 8<\/b>: The MS2_state_change_failure() <\/b>event rolls back the transaction on MS2<\/p>\n
Step 9<\/b>: Once the rollback is complete, MS2 fires and event called change_state_to_S1()<\/b> on MS1<\/p>\n
Step 10<\/b>: MS1 executes a logic on DB1 that rolls back the state of C1 from S2 to S1<\/p>\n
Step 11<\/b>: The new Timestamp is also recorded as T2<\/p>\n
Step 12<\/b>: Difference between T1 and T2 is recorded as time taken to complete the choreography<\/p>\n
<\/p>\n
Benefits and Limitations of Choreography-based Saga<\/strong><\/h5>\n
Customer Service:<\/em> responsible for maintaining customer records<\/p>\n In this case, a choreography-based saga would have the following steps:<\/p>\n <\/p>\n 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.<\/p>\n <\/p>\n Step 1<\/b>: External event fires a method is MS1 that\u00a0 changes the state attribute of C1 from S1 to S2. (This could be a client app)<\/p>\n Step 2<\/b>: DB1 saves the time T1 of the change in the TimeStamp attribute of C1<\/p>\n Step 3<\/b>: Once the updates is complete, MS1 fires an event called MS1_state_change_success()<\/b><\/p>\n Step 4<\/b>: MS1 calls a method change_state_to_S2() <\/b>on MS2<\/p>\n Step 5<\/b>: MS2 executes a logic on DB2 that changes the state attribute of collection C2 from S1 to S2<\/p>\n Step 6<\/b>: The logic fails<\/p>\n Step 7<\/b>: MS2 fires an event called MS2_state_change_failure()<\/b><\/p>\n Step 8<\/b>: The MS2_state_change_failure() <\/b>event rolls back the transaction on MS2<\/p>\n Step 9<\/b>: Once the rollback is complete, MS2 fires and event called change_state_to_S1()<\/b> on MS1<\/p>\n Step 10<\/b>: MS1 executes a logic on DB1 that rolls back the state of C1 from S2 to S1<\/p>\n Step 11<\/b>: The new Timestamp is also recorded as T2<\/p>\n Step 12<\/b>: Difference between T1 and T2 is recorded as time taken to complete the choreography<\/p>\n <\/p>\n\n
\n
\n
Choreography-based Saga Algorithm in Detail<\/strong><\/h5>\n
<\/a>The steps would be as follows:<\/strong><\/h5>\n
Benefits and Limitations of Choreography-based Saga<\/strong><\/h5>\n