What is a good practice for working with different message types in the Azure service bus

Question

I am new to using a Message based architecture such as the Azure Service Bus Topic/Subscription feature.

I am wondering how best to work with different message types.

E.g. Say I have two messages. One to create a new customer and another to delete a customer.

I could;

1. Create two topics. Each topic will have one subscription. The code that processes the message will deal with its message type independently.

2. Create one topic for customers. Create one subscription to receive all the messages. The code that processes the messages will need to determine the message type before processing it.

3. Create one topic for customers. Create two subscriptions, which filter the on the message type. The code that processes the message will deal with its message type independently.

I'm sure there is no right or wrong, but would appreciate some input from someone with experience in this area.

Many Thanks,

David

Answer 1

A few considerations for choosing Topics/Subs:

1. Will you have a Single node (process/app etc.) interested in different message types or a single message type. If you need a single application to process multiple message types (both add and delete) then best is to have a single topic. Then your app can listen to a single subscription and process both messages, you can also add more instances of your app to that single subscription. Later if you decide to separate that processing you can still create two different subscriptions and filter messages to have either add/delete messages sent to one or another.

2. If you system is focused on individual customers, say you are writing several services that will be per customer, then having a single topic per customer is good, because you can scale linearly with customers as well have clear authorization/processing boundaries between different customers. If however you are processing all customer requests through a single multi-tenant service and do not want to have different service instances per customer then this is not the best approach.

   Having a single topic to start with gives you a lot of flexibility and later on your can use ForwardTo to just channel messages from a single Subscription to another topic/Queue etc. as the system evolves. This allows you to create rich messaging topologies starting from a simple one.