Cosmos Change feed - Azure function cosmos trigger

Question

Will items from the same CosmosDB partition be processed by the same Azure Function instance (when scaled to multiple instances) or can multiple instances process updates from the same cosmos partition?

Our situation:

• We have a cosmos db table where we update items regularly
• A python azure function is triggered by a cosmos trigger to process all updates from our cosmos db table
• Our cosmos db is partitioned by item category number

In the documentation I read that:

Because Azure Functions uses the change feed processor behind the scenes, it automatically parallelizes change processing across your container's partitions.

Does this mean that updates originating from the same cosmos partition cannot be read by more than 1 azure function instance? The reason I ask is because we want to preserve the order of items within a category (indicated by their category number) while processing them, and this would be more likely when no more than 1 instance processes the same cosmos partition.

Answer 1

Hi Guusje
It sounds like you're trying to figure out how Azure Functions handles change feed events, particularly with respect to item ordering when using a partitioned Cosmos DB.

Based on what you've described, when you use Azure Functions with a Cosmos DB trigger, the function scales automatically, and changes from a single partition can indeed be processed by multiple instances. What this means is that if there are multiple changes happening within the same partition at roughly the same time, different function instances might handle those changes.

This can lead to potential issues with maintaining order if you want to ensure that items processed from the same category (or partition) are handled in the exact sequence they were updated. The Azure Functions trigger does parallelize processing across partitions to optimize throughput, which can disrupt the strict ordering of items within a single partition.

If maintaining order is a high priority for your application, here are a couple of suggestions:

1. Single Instance: Consider running a single instance of the Azure Function specifically for that partition, which guarantees that it processes events in order. However, be mindful that this approach may affect your overall throughput.
2. Custom Change Feed Processor: Alternatively, you could implement your own change feed processor, giving you more control over how documents are processed. This would allow you to design the processing in a way that respects the order of updates from each partition.

For more details, you can check this discussion and this explanation on how partition key ranges affect parallel processing. Let me know if you need further clarification!