Hi All! Today I would like to digress a bit about how it’s possible to use a Saga to orchestrate a very simple Order Processing workflow. We’re going to use OpenSleigh, of course, to do all the gruntwork for us.
We talked already about what Orchestration is and how it differs from Choreography in another post, so I’m not going to spend much time on this.
So, in a regular, microservice-based e-commerce, we usually have multiple services involved in the Order processing workflow. When the customer clicks “Buy” and finalizes her order, there’s a whole list of steps our system has to do.
We might have, for example:
- Inventory service, called to make sure we have products in stock
- Pricing service, called to fetch the exact price of the items
- Localization service, to retrieve the localized text to send back to the customer
- Shipping service, called to calculate the final shipping price
This is, of course, an oversimplification of what could happen. There are many other steps involved, just think of Coupons, Credit check, Customer loyalty and so on.
Organizing this workflow, or multiple workflows like this can be quite overwhelming. OpenSleigh can be leveraged as central node, turning our architecture into an event-based, asynchronous, reactive system.
We can use a Saga to handle a
Process Order command from the main user-facing application. OpenSleigh will start a new Saga instance and initiate the process.
The message handler can send multiple commands to the underlying microservices, for example, to check the inventory and to process the payment.
Each individual microservice will publish an event once it’s work is complete. The Saga can subscribe to those events, and wait for all of them before triggering the last step.
That’s all for today! The next time we’ll go a bit more into the details and take a look at some sample code.