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.
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.
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.