Consuming Service Bus Topic with App Service that is scale-out

Lachezar Dobrev 6 Reputation points

Currently it seems that receiving messages from a Service Bus Topic with an App Service that has been scaled-out (2 or more instances) requires jumping through hoops:

Subscribing to a Topic requires a preemptively created subscription.

If all instances share the same subscription messages are delivered to only one instance (as with a Queue).
This is not the desired behaviour!

  1. Possible solution: create multiple subscriptions, configure every instance to use a different one.
    This does not seem to be possible when using App Service.
    One configuration is shared for all App Service instances.
  2. Possible solution: every instance creates a subscription with a random name.
    This requires that App Service instances have Service Bus credentials with MANAGE permission, which is dangerous.
    This requires additional code that requires additional dependencies (on Azure Management API).


  • spring-boot-starter-parent:2.5.4
  • spring-messaging:5.3.9
  • azure-servicebus-jms-spring-boot-starter:2.3.5

Please advise on a reliable way to listen to an Azure Service Bus Topic with a scaled-out (2+ instance) App Service using JMS, so that every message is received by every instance.

Azure Service Bus
Azure Service Bus
An Azure service that provides cloud messaging as a service and hybrid integration.
586 questions
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,336 questions
{count} vote

2 answers

Sort by: Most helpful
  1. Samara Soucy - MSFT 5,051 Reputation points

    Each topic subscription does indeed act like a queue would. Subscriptions exist in order to ensure that there is a distinction between receivers working on the same set of messages (a single subscription or a queue) and receivers working on their own distinct copy of messages (multiple subscriptions).

    Lets say I have a topic that is receiving requests to resize photos. I want to receive messages to resize the photo and a separate set of messages for logging. Logging might be fine with a single receiver, but as resizing work scales up maybe I want to have three receivers. I don't want to resize each photo three times, one for each receiver, I want each request to be handled once for resize and once to log. In this case I would make two subscriptions. The logger would feed from one subscription and all three resize workers would feed from the other. Auto-scaling usually reflects this- each instance is doing the same job, so you don't want duplicate messages in order to avoid doing duplicate work.


    I'm trying to scale-out my app and I'm having a problem, only oneof my apps is getting a message from a subscription and all others don't do anything. It seems like an one app is the master and it reads all messages and others are slaves.

    How do i solve this ?

    The app has min replica 5 and max 15

    0 comments No comments