CODEWITHSUNDEEP
azureazure-functionsazureservicebus
Kzryzstof
Kzryzstof

Reputation: 8382

Scaling out of a Function App with Service Bus trigger

The documentation regarding the scaling of Function App using Event Hub trigger states that:

The trigger (powered by Event Hubs) ensures that only one EventProcessorHost instance can get a lease on a given partition.

...

As scaling occurs, N instances [of the Function App] is a number greater than the number of event hub partitions

Considering that I have an Event Hub configured with 32 partitions, under load, I understand why the Function App scales out to -at least- 32 instances, each locked on to a specific partition.

Context

I want to replace the Event Hub by a Service Bus instead.

All the messages sent in the Service Bus are being set a Session ID to guarantee order.

As explained in the documentation, the Session ID will be used as a Partition Key which means I will have a lot of partitions (i.e. over 20,000 - which is Ok... I think).

Question(s)

How does the scaling of the Function App work in that regard? Are the Service Bus partitions tied to an instance of the Function App like it is done with Event Hubs? Or any instances of the Function App can get messages from any partitions?

Upvotes: 1

Views: 560

Answers (1)

PramodValavala
PramodValavala

Reputation: 6647

Partitioning in Service Bus is a functionality through which the throughput of a queue or topic is greatly increased by using multiple brokers behind the scenes. The clients aren't really aware of this when connecting and work as if it were a regular queue or topic.

So, an Azure Function can't scale out to the number of partitions that it does not know of.

Instead, it simply scales up as more and more messages are waiting to be processed in the queue or topic, based on how many messages are waiting to be processed.

Upvotes: 2

Related Questions