Saga design pattern and transaction in Microservices architectures

When the user places an order for any product, the 'Order' service will perform this operation and add it to its own database. The 'Payment' service will provide the payment and if the payment is successful, it will reduce the stock amount corresponding to the relevant product in the 'Stock' service.
Transaction status

ACID properties of transactions

As a result of any data interference with a software on distributed databases, we evaluate how this process will be implemented in line with certain principles.
In Choreography, each service queue listens. If there is a message that comes according to the event message type it listens, it performs the necessary operations and as a result, it adds the successful or unsuccessful information to the queue as an event. Then, other services will either continue their functions according to this event, or all transactions will be restored and data consistency will be ensured.
  • order-services receives a POST request for a new order
  • It places an order request in the DB in the ORDER_CREATED state and raises an event
  • payment-service listens to the event, confirms about the credit reservation
  • inventory-service also listens to the order-event and conforms the inventory reservation
  • order-service fulfills order or rejects the order based on the credit & inventory reservation status.
Abstract : In this implementation, it is essential to communicate with each other through events without a central control and communication point between microservices. In other words, he argues that communication between services should be designed asynchronously.
  1. Order Service saves a new order, set the state as pending and publish an event called ORDER_CREATED_EVENT.
  2. The Payment Service listens to ORDER_CREATED_EVENT, charge the client and publish the event BILLED_ORDER_EVENT.
  3. The Stock Service listens to BILLED_ORDER_EVENT, update the stock, prepare the products bought in the order and publish ORDER_PREPARED_EVENT.
  4. Delivery Service listens to ORDER_PREPARED_EVENT and then pick up and deliver the product. At the end, it publishes an ORDER_DELIVERED_EVENT
  5. Finally, Order Service listens to ORDER_DELIVERED_EVENT and set the state of the order as concluded.

Rollbacks in distributed transactions

  1. Stock Service produces PRODUCT_OUT_OF_STOCK_EVENT;
  2. Both Order Service and Payment Service listen to the previous message:

Benefits and drawbacks of using Saga’s Event/Choreography design

As its other name, Saga State Machine, can be understood, Saga Orchestrator keeps the application state of each request from each user, interprets it and applies compensatory operations when necessary.
  1. Order Service saves a pending order and asks Order Saga Orchestrator (OSO) to start a create order transaction.
  2. OSO sends an Execute Payment command to Payment Service, and it replies with a Payment Executed message
  3. OSO sends a Prepare Order command to Stock Service, and it replies with an Order Prepared message
  4. OSO sends a Deliver Order command to Delivery Service, and it replies with an Order Delivered message

Rolling Back in Saga’s Command/Orchestration

  1. Stock Service replies to OSO with an Out-Of-Stock message;
  2. OSO recognizes that the transaction has failed and starts the rollback
    2.1 In this case, only a single operation was executed successfully before the failure, so OSO sends a Refund Client command to Payment Service and set the order state as failed
Here, in case of an error or a failure of the transaction, the orchestrator receives the information that there is a failure in the transaction process and starts the rollback transactions(Compensable Transaction)Keeping state information on Saga for each process will make it easier to see which step you mismanaged the process.

Benefits and Drawbacks of Using Saga’s Command/Orchestration Design

  • Avoid cyclic dependencies between services, as the saga orchestrator invokes the saga participants but the participants do not invoke the orchestrator
  • Centralize the orchestration of the distributed transaction
  • Reduce participants’ complexity as they only need to execute/reply commands.
  • Easier to be implemented and tested
  • The transaction complexity remains linear when new steps are added
  • Rollbacks are easier to manage
  • If you have a second transaction willing to change the same target object, you can easily put it on hold on the orchestrator until the first transaction ends.
The links to the sources I used during the writing period are below.Sources:




Java Software developer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Want to write great technical documentation? Work in Support

Always Catch M ost Specific Exception

Tutorial 3 — Working with Spatial Data in Grasshopper

Using Firebase Auth in Insomnia

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Java Software developer

More from Medium


Ruling the Event-Driven Architecture with RabbitMQ

Splitting monolithic systems into microservices

What is Service Discovery & why it is important in Microservices. Described in less than 4 minutes.