I’m planning to use publish–subscribe pattern with Azure Service Bus in my logistics application, but I’m confused whether publish–subscribe pattern is suitable for my case.
My scenarios:
-
Users will subscribe set of topics such as reset password, change password, load assign, user approval, user rejection etc.
-
80% topics, such as reset password or change password, are specific to a single user and will be delivered to only that particular user if subscribed.
-
In some topics, multiple users will be involved such as driver, carrier, shipper. But all the three need to receive three different messages for same event or topic.
Questions:
-
If I have one topic and one subscriber, do I really need publish–subscribe pattern? Am I missing something?
-
Should all subscribers receive same message for a topic? If I send different messages for same event for different users, am I misusing publish–subscribe pattern?
I wouldn’t worry about misusing the pattern but in the scenarios you describe I don’t think you need it.
PubSub seems to be the popular default at the moment for any messaging application but there is a simpler version of it for when you don’t need to fan out or fan in the messages.
Just use messaging. There are different forms:, http, rpc, MQ, callbacks. If you need to be able to send the messages asynchronously and they might get backed up then use a queue.
After that it comes down to what technologies you know / are willing to learn, and exactly the quality of service requirements / reliability requirements / different speeds of the different components in your system, which you don’t go into here.