'What are the disadvantages of an azure service bus topic with only one subscription compared to a queue
I'm currently studding Azure Service Bus and I didn't understand the real benefits of a Queue compared to a Topic with a single Subscription. I see that in both cases it's possible to create different applications in listening to the single queue (or subscription) to process the messages faster.
So what is the real convenience to use a queue of an azure service bus, if with the topic it can work in the same way? Better Performance? It's cheaper?
Solution 1:[1]
Service Bus Queues offers messaging via one sender and one receiver. Where as, Service Bus Topics supports multiple receivers.
Subscriptions can be created under the Topics to subscribe messages.
Each Subscription under a Topic acts like a Queue.
The messages will be sent to the Topic and based on the filter configured in the Subscriptions, the messages will be passed to the Subscriptions.
In your case, if you are sure that there will be only one receiver, you can go with Queues.
If you think that the number of receivers may grow in future and you need the messages to be filtered before making it available for the receiver, you can choose Topics.
Considering the performance, there won’t be much difference in the performance between Queues and Topics. But in Topics, the messages will go through the Topic first and based on the evalutaion of the filter, the message reaches the Subscription. Here there may be minute performance lack in Topics as this step is extra. Where as in Queues, the messages will be sent directly to the Queue.
The pricing is calculated based on the number of messages, whether it is Queue or Topic. You can’t create Topics under the namespaces which are in Basic tier.
Solution 2:[2]
So what is the real convenience to use a queue of an azure service bus, if with the topic it can work in the same way? Better Performance? It's cheaper?
None of the above. Performance impact is insignificant, especially if your filter is a TrueFilter (no filtering). What you do gain is some flexibility with your topology you'd not be able to achieve with a plain queue. For example, ability to add a temporary wiretap to troubleshoot your messages. Or adding an audit of all the messages received.
Solution 3:[3]
The decision to use a Queue or Topic depends on the use case. Is it pub/sub, then you use a Topic and subscriptions. If you need the producer/consumer pattern, where each message should be processed just once by a consumer, you use a queue. So the Queue is not only intended to be used if you have one receiver, you can have multiple receivers, but a message will only be fetched by one receiver not all the receivers that are connected to the queue. So if your one consumer has problems to keep up with the rate messages are being sent to the queue, you can add more consumers to speed up the processing.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Arunprabhu |
| Solution 2 | Sean Feldman |
| Solution 3 | Stefan |