{"id":1218,"date":"2018-01-16T01:10:02","date_gmt":"2018-01-16T09:10:02","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/saga-pattern-implement-business-transactions-using-microservices-part-2\/"},"modified":"2018-01-16T01:10:02","modified_gmt":"2018-01-16T09:10:02","slug":"saga-pattern-implement-business-transactions-using-microservices-part-2","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/saga-pattern-implement-business-transactions-using-microservices-part-2\/","title":{"rendered":"Saga Pattern | How to Implement Business Transactions Using Microservices \u2013 Part II"},"content":{"rendered":"\n

\"\"<\/a><\/p>\n\n\n\n

In the previous post<\/a>, we saw some of the challenges of implementing distributed transactions and how to implement Saga\u2019s pattern using the Event\/Choreography approach. In this article, let\u2019s talk about how to address some of its problems like complex transactions or cyclic dependencies of events by using another type of Saga\u2019s implementation called Command or Orchestration.<\/span><\/p>\n\n\n\n

\u00a0<\/p>\n\n\n\n

Saga\u2019s Command\/Orchestration Sequencing Logic<\/b><\/h3>\n\n\n\n

In the orchestration approach, we define a new service with the sole responsibility of telling each participant what to do and when. The saga pattern<\/a> orchestrator communicates with each service in a command\/reply style telling them what operation should be performed.<\/span><\/p>\n\n\n\n

Let\u2019s see how it looks like using our previous e-commerce example:<\/span><\/p>\n\n\n\n

\"Command\/Orchestration<\/p>\n\n\n\n

    \n
  1. Order Service<\/em> saves a pending order and asks Order Saga Orchestrator (OSO) to start a create order transaction<\/em>.<\/span><\/li>\n\n\n
  2. OSO<\/em> sends an Execute Payment<\/strong><\/em> command to Payment Service<\/em>, and it replies with a Payment Executed<\/strong><\/em> message<\/li>\n\n\n
  3. OSO<\/em> sends a Prepare Order<\/strong><\/em> command to Stock Service, and it replies with an Order Prepared<\/strong><\/em> message<\/li>\n\n\n
  4. OSO<\/em> sends a Deliver Order<\/strong><\/em> command to Delivery Service, and it replies with an Order Delivered<\/strong><\/em> message<\/li>\n\n<\/ol>\n\n\n\n

    In the case above, Order Saga Orchestrator knows what is the flow needed to execute a \u201ccreate order\u201d transaction. If anything fails, it is also responsible for coordinating the rollback by sending commands to each participant to undo the previous operation.<\/span><\/p>\n\n\n\n

    A standard way to model a saga orchestrator is\u00a0a State Machine where each transformation corresponds to a command or message. State machines are an excellent pattern to structure a well-defined behavior as they are easy to implement and particularly great for testing.<\/span><\/p>\n\n\n\n

    \u00a0<\/p>\n\n\n\n

    Rolling Back in Saga\u2019s Command\/Orchestration<\/b><\/h3>\n\n\n\n

    Rollbacks are a lot easier when you have an orchestrator to coordinate everything:<\/span><\/p>\n\n\n\n

    \"\"<\/p>\n\n\n\n

      \n
    1. Stock Service<\/span><\/i> replies to OSO with an <\/span>Out-Of-Stock<\/i><\/b> message;<\/span><\/li>\n\n\n
    2. OSO recognizes that the transaction has failed and starts the rollback<\/span>\n
        \n
      1. In this case, only a single operation was executed successfully before the failure, so <\/span>OSO<\/span><\/i> sends a <\/span>Refund Client<\/i><\/b> command to <\/span>Payment Service<\/span><\/i> and set the order state as failed<\/span><\/li>\n<\/ol>\n<\/li>\n\n<\/ol>\n\n\n\n

        \u00a0<\/p>\n\n\n\n

        Benefits and Drawbacks of Using Saga\u2019s <\/b>Command\/Orchestration Design<\/b><\/h3>\n\n\n\n

        Orchestration-based sagas have a variety of benefits: \u00a0<\/span><\/p>\n\n\n\n