1

I am trying to understand what's the best practice here in this specific use case of ours.

  1. We have an Orders Microservice.
  2. We have to accept requests via an API from user-facing client apps that is directed to our processing logic.
  3. We have to also read from a Service Bus Queue to which a third-party system sends webhooks to, and that payload needs to be processed by the exact same Order processing logic.

What is the best practice to architect this? I can think of 3 approaches:

  1. Have an API exposed from the Orders Microservice and also have a Service Bus Queue consumer on the same service, which reads from the Queue and sends it to order processing logic. Here except for the method through which we receive the request (API vs. Queue) everything remains the same. But I have a feeling that an API and a Worker (listening to queue) being present in a single app service is not a good practice and causes deep coupling.

  2. Another approach is to only Expose an API from the Order Microservice and do not have a queue consumer there. Create a new app service (.net core worker) that reads from the queue and then POSTs the payload to the Orders API. This seems like a better approach, but we have several microservices just like the Orders service and do not want to take the overhead of creating one AppService/Worker per queue since consuming from multiple queues from a single worker/app service is not a good practice.

  3. Third approach is to have an Azure Event Grid read from the Service Bus Queue and then post it to the Orders API. This way we can easily create Topics and Subscriptions and direct service bus queue messages to API without much overhead.

Please provide recommendations based on Microservices Best Practices.

Illustration of the 3 approaches:

user1220169
  • 805
  • 2
  • 9
  • 14
  • Using the Azure Event Grid (AEG) in your option 3 is not correct. see the following document https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-to-event-grid-integration-concept for more details about the eventing from the Azure Service Bus resource. In other words, your microservice needs an AEG subscriber for pulling a message from the service bus queue entity. – Roman Kiss May 03 '23 at 03:13
  • Got it. Looks like Event Grid can be used to send an event to a consumer indicating that it can now pick up a message from the queue. Not necessarily pick the message itself from the queue and send it to a consumer. Is Option 1 or 2 considered a good approach then? If so, which one is better? – user1220169 May 03 '23 at 19:46

1 Answers1

0

Architectural decisions are based on multiple factors but providing you one more option

Option 4

Actor -----> API  <--------- Vendor System

             |
             |
             V

     Service Bus Queue

             |
             |
             V
     Orders Microservice

This achieves two things

  1. You can expose a common REST API for both Actors/Vendor Systems.
  2. Does Load Levelling for Orders Micro service

Don't look at a Service Bus as an input mechanism, look at it in terms of what architectural traits it brings like load levelling / retry / buffer etc.

Shinva
  • 1,899
  • 18
  • 25
  • thank you for your answer. The reason this will not work out for us is, the Vendor Systems does not expect a synchronous response back for the order. The Users (Actors) however require a synchronous response about the result of the order processing and this is displayed on the UI. Whereas no UI is involved in the VendorSystems flow and is fully asynchronous. I know we can implement some sort of push mechanism to the UI (using websockets / server-sent events) to update UI of the status, however that will be a far fetch for our budget right now. – user1220169 May 03 '23 at 13:28