Choreography Saga Pattern With Spring Boot — Microservice Design Patterns

A Simple Transaction:

Let’s assume that our business rule says, when an user places an order, order will be fulfilled if the product’s price is within the user’s credit limit/balance. Otherwise it will not be fulfilled. It looks really simple.

Saga Pattern:

Each business transaction which spans multiple Microservices are split into Microservice specific local transactions and they are executed in a sequence to complete the business workflow. It is called Saga. It can be implemented in 2 ways.

  • Choreography approach
  • Orchestration approach

Event Sourcing:

In this approach every change to the state of an application is captured as an event. This event is stored in the database /event store (for tracking purposes) and is also published in the event-bus for other parties to consume.

  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!
  • There is no service dependency. payment-service/inventory-service do not have to be up and running always.
  • Loose coupling
  • Horizontal scaling
  • Fault tolerant
  • 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.

Implementation:

  • I created a simple Spring Boot project using kafka-cloud-stream. I have basic project structure which looks like this.
  • It contains the basic DTOs, Enums and Event objects.

Payment Service:

The payment service consumes order-events from a kafka topic and returns the corresponding payment-event. Take a look at the GitHub link at the end of this article for the complete working project.

Inventory Service:

We also have inventory-service which consumes order-events and returns inventory-events.

Order Service:

We first create a Sink through we which we would be publishing events.

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

Demo:

  • Once I start my application, I send an order request. The productId=3 costs $300 and user’s credit limit is $1000.
  • 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.

Summary:

We were able to successfully demonstrate the Choreography Saga Pattern with Spring Pattern.

--

--

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

Vinoth Selvaraj

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