Azure Service Bus Topic-with paired or retry

0
votes

We are using Azure Service Bus Topic in workflow manager (approval process). In any way, we don’t want to lose/duplicate messages when we push messages to service bus topic. Now there are two options. a. Use Retry the only b. Use Paired service bus only without retry. As we cannot use both together, let assume during message push, primary service bus is not available then message pus to paired service bus and when primary service bus available then automatically message push to the primary. But if we use retry, retry will try to push message to primary and as primary service bus is not available messages will go to paired service bus also. so there are chances to process duplicate messages.

Which is the best option “a” or “b”, to push message to service bus for the given problem statement?

1
azure-servicebus-topics
Are you referring to Paired Namespaces feature? If yes, paired namespace is solely used as a temporary storage while the primary namespace is down. It is not used to process messages. – Sean Feldman
@SeanFeldman Yes, Paired namespaces, I know it will not process a message. once primary service bus is available then secondary push message to primary one. in case "a" and "b" which is most suitable approach to push message to Primary service bus ? – Rukhsar Ahmad
I'm not a big fan of PairedNamespace. Will leave an answer. – Sean Feldman

1 Answers

1
votes

Both options have their pros and cons. With Paired Namespaces you get the ability to continue sending messages while your primary namespace is down. But don't get fooled. You only store those messages while the primary namespace is down. They are not retried by the reveiver. Other drawbacks include

  • No good testability.
  • Increased cost (you send to the secondary, retrieve back from it to send to the primary).
  • Failover to the secondary is not very intuitive. You have to manually retry the message after a failure. It is not automatically switches to the secondary namespace.

Have a look at this post for more details.

With retries approach you gain the simplicity. And something you'd need to do anyways. With Azure Service Bus operations can fail with intermittent exceptions and you should retry anyways. The drawback of having only retries - doesn't protect from outages. That's why you could combine it with a secondary namespace using custom implementation, but that's a whole different can of warms. Libraries like NServiceBus provides a custom implementation you can get the idea from.