CODEWITHSUNDEEP
azureservicebusazure-servicebus-queuesmessagebrokerazure-servicebus-topicsevent-driven
Alexander Bikkuzhin
Alexander Bikkuzhin

Reputation: 93

Mix Commands with Events in message broker(ServiceBus)

I have Order and OrderProcessor services. After the Order has submitted it must be processed by OrderProcessor. After processing the OrderProcessor should send the response to the Order service with Order status e.g. Failed/Succeeded. I would like to have async processing and decouple my services using message broker(Azure ServiceBus).

In terms of Commands and Events I see the following structure:

There a couple of ways to achieve it in ServiceBus using either Queues or Topic(s). I would like to use one shared Topic where both ProcessOrder message and OrderProcessedFailed/OrderProcessedSucceeded events will be published. And each service will have it's own Subscription with Filter by event type.

I know that shared Topic structure is a good choice for simple scenarios when you have event-driven approach. But in my case I also have ProcessOrder command. I'm expecting that Order will be processed. It's not the same when I just raise OrderCreated event(or whatever) and expect any reactions to it.

Is it actually a good way to mix Command and Events in one shared Topic or mix Command and Events at all? Will it be better to use message-driven approach with request and reply Queues. And replace response events with OrderReply message(with Failed/Succeeded status inside)?

Additional information:

I'm not sure will it be any other Commands or/and Events in future. But if so it defiantly better to have structure with easy to maintain such as shared Topic for all Services.

What I know right now that different versions of OrderProcessors should be supported. And I believe it's easier to handle Command message version using Topic and Subscribers with Filters. Rather than just filter messages on application level.

Upvotes: 0

Views: 490

Answers (1)

PerfectlyPanda
PerfectlyPanda

Reputation: 3501

There's not necessarily a hard rule on this, but the approach I personally would take would be one for commands and one for events- aka 1-1 mapping between topic and purpose. There is nothing wrong with using a topic with a single subscriber if you need the ability to expand that as you build on the service.

Adding different OrderProcessors would probably be a good use of the filters, either within the service or in your code. They can each have their own subscription to the command topic and that way the Order service doesn't need to know anything about which processor a given command will end up with.

The next thing to consider would be adding a completely different type of service to the mix- say something that receives commands from the OrderProcessors. If you ultimately expect the number of services to grow quite large with complex connections, then having that central command topic will likely be a good choice- it allows commands from any component to move to any other component.

On the other hand, if your types of services remains on the lower side, then it may make sense to define purpose more narrowly- say separating orderCommands and inventoryCommands. It wouldn't be wrong to use a single command topic in that scenario either if that's the design you would prefer.

You could also combine the two using auto-forwarding. Your central command topic receives all messages and then auto-forwards them to the orderCommands and inventoryCommands topics. In a large system, that keeps the number of subscriptions you are managing for a single topic down a bit.

Upvotes: 1

Related Questions