0

I am trying to design the strategy that my organization will employ to create topics, and which messages will go to which one. I am looking at either creating a separate topic for each event, or a single topic to hold messages from all events, and then to triage with filters. I am convinced that using a separate topic for every event is better because:

  • Filters will be less complex and thus more performant, since each event is already separated in its own topic.
  • There will be less chance of message congestion in any given topic.
  • Messages are less likely to be needlessly copied into any given subscription.
  • More topics means more messaging stores, which means better message retrieval and sending.
  • From a risk management perspective, it seems like having more topics is better. If I only used a single topic, an outage would affect all subscribers for all messages. If I use many topics, then perhaps outages would only affect some topics and leave the others operational.
  • I get 12 more shared access keys per topic. It's easier to have more granular control over which topics are exposed to which client apps since I can add/revoke access by add/revoking the shared access key for each app on a per-topic basis.

Any thoughts would be appreciated

Extranomical
  • 385
  • 1
  • 3
  • 13

1 Answers1

0

Like Sean already mentioned, there is really no one answer but here are some details about topics that could help you.

  1. Topics are designed for large number of recipients by sending messages to multiple (upto 2000) subscriptions, which actually have the filters
  2. Topics don't really store messages but subscriptions do
  3. For outages, unless you have topics across regions, I'm not sure if it would help as such
  4. The limit is for shared access authorization rules per policy. You should be using one of these to generate a SAS key for your clients.

Also, chaining service bus with autoforwarding is something you could consider as required.

PramodValavala
  • 6,026
  • 1
  • 11
  • 30