Microservices Saga pattern consumer awaits response

Question

I would like to clarify what'd be the best way of organizing architecture.

I've got rest api and microservices architecture. I have applied the Database per Service pattern.

So let's imagine that the user wants to create an order(an e-commerce system). But users can have a credit limit. So the flow will be as below:

• OrderService creates a pending order. Then push an event about it.

• UserService processes that event and publishes either a credit limit exceeded event or a credit reserved event.

• OrderService receives the event and changes the state of the order to either approved or canceled.

All look good. But the question is what the user will do during this simple flow? I mean: the user makes a POST request /orders and ...

1. Web-service awaits until the order gets approved or canceled(includes surely timeout)?
2. Web-service returns 200 ok and then the user needs to check the order state with some interval?
3. use web sockets?
4. something else?

Unfortunately, Any option from above has its advantages and its disadvantages.

The challenge is that I described the simplest case. In reality, tens services(even third party) could be involved. And of course, I am expecting a high load. So the queue may be filled.

Please propose the solution to discuss. I'm greatly appreciating for an answer as well as links to production ready system documentation.

Answer 1

Kudos for a good question. If we look at Saga Pattern, it offers to do ACID like transactions in a distributed system but with some trade-off. One of the trade-offs is Ensuring Rollback if any of the service or entity fails to do what it was supposed to do. This can go even complex if you have more than 5 services completing a Saga. Though it will be a Highly Scalable option if you can orchestrate.

Here I will propose Following,

• User Does a POST request for order
• OrderService first checks with UserService regarding credit Limit (It can be a REST API call as it might be a simple DB call for UserService)
• Then OrderService can act upon based on the return response from UserService

Advantages of this approach

• User can see an immediate response
• Less Complex to code thus testable and maintainable Code

Disadvantages of this approach

• This solution will not be effective if there are too many external (third party) rest api calls
• It can introduce single point of failure

The main thing is, all the options will have trade-offs. It is on you to decide which one suits you the best.

Answer 2

The question is what the user will do during this simple flow? I mean: the user makes a POST request /orders and ...

You can reply to user the created orderId with status 'pending' while your saga is running. The request should be ended in 200.

How does user get the status?

Push notification, websocket, email, sms. it is up to you to notify the user about the status of event, success, failure, waiting_for_approval.

1. Web-service awaits until the order gets approved or canceled?
2. Web-service returns 200 ok and the user check the order state with some interval?
3. use web sockets?
4. something else?

1. Not recommended. Saga should be asynchronous. Waiting for reply is synchronous (request/reply style).
2. This will work, but if your saga is long running, it might be problematic, eg: anything with validation/approval by a human.
3. This will work assuming you are replying 200 after order creation in pending state, one thing is that you have to make sure your websocket is active, or else, you still have to notify them through email, sms.

Unfortunately, Any option from above has its advantages and its disadvantages.

You have to choose your poison.

The challenge is that I described the simplest case. In reality, tens services(even third party) could be involved. And of course, I am expecting a high load. So the queue may be filled.

Use orchestrated saga (sort like) Netflix conductor, Uber Cadence, Temporal (Similar to Cadence). This will allow you to do something as shown below. At least, easier.

A flow diagram from google shopping api and how they handle it.

Link for more: https://developers.google.com/shopping-content/guides/about-orders