Azure Service Bus Queue vs Topic EXPLAINED

[@allahousalami]

thanks a lot very clear and helpful

[@muhammadabuhuraira2407]

From what I understand Topic/Sub is just a simple Queue but the message is send to multiple subs just like in a pub/sub model and one sub consuming that message does not remove the message from other subs.

[@bmrreddy2002]

Sounds like topics is similar to consumer groups in Event Hubs

[@bogdanb904]

Given the scenario of 2 different consumers that are scaled out (X instances for each consumer), how would a topic subscription behave? Would all the instances receive the message? Or only one instance per each consumer type?

[@dantealexis7835]

Hey so is it that the only thing that will remove a message from a topic is that message lifetime attribute? Is it uncommon to try to determine when all subscribers have consumed the message and manually remove the message? And just so I have it right, the message will be removed from a queue (as opposed to a topic), not only based on the lifetime, but as long as it's picked up by a consumer of said queue?

[@anonymoos]

Excellent explanation, thanks Dan! Follow up question though, how long does the processor have to mark the message as complete before another processor will pick up the same message? Is that built-in to the service bus, or is that something to implement on the processor side?

[@Codewrinkles]

Yep, when you create a topic or a queue you can define message lifetimes and other similar settings. If messages are then not picked up in that time frame, those messages are discarded.

[@afgone123456]

How about adding filter to topic subscription and send to only one subscription then have multiple consumers listening to that subscription only?

[@Codewrinkles]

That doesn't really jhelp as subscriptions behave similar to queues. One consumer will pick it up, but you don't know which one.