0

If I, in Azure, create a

  • Queue

or

  • Topic with one catch-all Subscription

What is the difference?

TL;DR

I know that one can add more Subscriptions later on, and I know about filtering for the Subscriptions. But that is not part of the question.

Same: There is one dead letter queue.
Same: Each message gets handled once-and-only-once.
Difference: ?

LosManos
  • 7,195
  • 6
  • 56
  • 107
  • 1
    By default, there is no guaranteed order of messages when using topics. Queues do FIFO delivery of messages. Also *once-and-only-once* is not true, both do at-least-once unless [deduplication](https://learn.microsoft.com/en-us/azure/service-bus-messaging/duplicate-detection) is enabled. – Peter Bons May 25 '23 at 11:22
  • @PeterBons Is this really true? Checking [docs](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions) I read "...The message-sending functionality of a queue maps directly to a topic and its message-receiving functionality maps to a subscription..." Without finding evidence of the opposite (which there might be) a Topic should be FIFO too. – LosManos May 26 '23 at 10:09

1 Answers1

1

You're focusing on the receiving. The real difference is on the sending side.

  • When a message is sent to a queue, the sender targets a specific destination. This message type is often called a command.
  • When a message is published to a topic, it will be received by zero or more subscribers. This message type is often called an event.

With commands, the sender and the single receiver are coupled. With events, the sender and the receiver(s) are decoupled.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Same same then. I put a message on a Queue or Topic. The sole reader of a Queue, or the sole reader of a Topic gets the message; in the order they are sent. – LosManos May 26 '23 at 10:05
  • Nope. It's only the same if you have a single subscription with catch all rule. And if you do that, you're killing a mosquito with a cannon – Sean Feldman May 26 '23 at 14:16
  • Single subscription with a catch all rule was the original question. – LosManos May 27 '23 at 19:48
  • You're still missing the point I tried to convey. Topics and subscriptions are for decoupled senders and receivers. With a queue, there's always coupling because the sender has to know the receiver's queue. But if your app is basic and that's not an issue, then use a simple solution, rather than setting up 2 entities. – Sean Feldman May 28 '23 at 00:23
  • I believe I get your point. My counter point is that 2 resources [Topic and Subscription] is not many more (well... double the amount...) than 1 [Queue]. So if I get into the habit of creating 2 resources, instead of 1, I get other functionality to use later. Like setting up a new catch-all subscription for eaves dropping live for debugging. Whether using a Topic instead of a Queue is a _good Idea_ or not is not askable on SO. Hence the limitation of my original q. – LosManos May 29 '23 at 09:25