Choreography Saga Pattern With Spring Boot — Microservice Design Patterns

Over the years, Microservices have become very popular. Microservices are distributed systems. They are smaller, modular, easy to deploy and scale etc. Developing a single microservice application might be interesting! But handling a business transaction which spans across multiple Microservices is not fun! In order to complete an application workflow / a task, multiple Microservices might have to work together.

Lets see how difficult it could be in dealing with transactions / data consistency in the distributed systems in this article.

A Simple Transaction:

This is very easy to implement in a monolith application. The entire workflow can be considered as 1 single transaction. It is easy to commit / rollback when everything is in a single DB. With distributed systems with multiple databases, It is going to be very complex! Lets look at our architecture first to see how to implement this.

We have an order-service with its own database which is responsible for order management. Similarly we also have payment-service which is responsible for managing payments. So the order-service receives the request and checks with the payment-service if the user has the balance. If the payment-service responds OK, order-service completes the order and payment-service deducts the payment. Otherwise, the order-service cancels the order. For a very simple business requirement, here we have to send multiple requests across the network.

What if we also need to check with inventory-service for the availability of inventory before making the order as complete! Now you see the problem?

In the traditional system design approach, order-service simply sends a HTTP request to get the information about the user’s credit balance. The problem with this approach is order-service assumes that payment-service will be up and running always. Any network issue or performance issue at the payment-service will be propagated to the order-service. It could lead to poor user-experience & we also might lose revenue. Let’s see how we could handle transactions in the distributed systems with loose coupling by using a pattern called Saga Pattern with Event Sourcing approach.

Saga Pattern:

  • Choreography approach
  • Orchestration approach

In this article, we will be discussing the choreography based approach by using event-sourcing. For orchestration based Saga, check here.

Event Sourcing:

The order-service receives a command to create a new order. This request is processed and raised as an order-created event. Couple of things to note here.

  1. Order created event basically informs that a new order request has been received and kept in the PENDING/CREATED status by order-service. It is not yet fulfilled.
  2. The event object will be named in the past tense always as it already happened!

Now the payment-service/inventory-service could be interested in listening to those events and reserve/reject payment/inventory. Even these could be treated as an event. Payment reserved/rejected event. Order-service might listen to these events and fulfill / cancel the order request it had originally received.

This approach has many advantages.

  • There is no service dependency. payment-service/inventory-service do not have to be up and running always.
  • Loose coupling
  • Horizontal scaling
  • Fault tolerant

The business workflow is implemented as shown here.

  • 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.


My common-dto package is as shown below.

  • It contains the basic DTOs, Enums and Event objects.

Payment Service:

Inventory Service:

Order Service:

  • order events publisher
  • Order service also consumes payment and inventory events to take decision on the order.
  • I am unable to provide the entire project code here. So do check the GitHub link at the end of this article for the complete source code.


  • As soon as I send a request, I get the immediate response saying the order_created / order_pending.
  • I send 4 requests.
  • If I send /order/all requests to see all the orders, I see that 3 orders in fulfilled and the 4th order in cancelled status as the user does not have enough balance to fulfill the 4th order.
  • We can add additional services in the same way. For ex: once order-service fulfills the order and raises an another event. A shipping service listening to the event and takes care of packing and shipping to the given user address. Order-service might again listen to those events updates its DB to the order_shipped status.

As we had mentioned earlier, committing/rolling back a transaction which spans multiple microservices is very challenging. Each service should have the event-handlers, for committing / rolling back the transaction to maintain the data consistency, for every event it is listening to!


Learn more about other Microservices Design Patterns:

The source code is available here.

Happy learning :)



Principal Software Engineer — passionate about software architectural design, microservices.

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
Vinoth Selvaraj

Principal Software Engineer — passionate about software architectural design, microservices.