Examkin

Question

Difficulty: Very hardProcess Azure Cosmos DB Change Feed Notifications

You are developing a microservice using the Azure Cosmos DB .NET SDK v3 to process product updates from a source container partitioned by `/productId`. The microservice is deployed as multiple instances in an Azure Kubernetes Service (AKS) cluster to handle high-throughput workloads.

You notice that when multiple instances of the service run concurrently, they all process the exact same partition updates, resulting in duplicate processing and database write conflicts in downstream services.

The microservice initializes the Change Feed Processor using the following code:

csharp
Container source = client.GetContainer("Db", "Catalog");
Container leases = client.GetContainer("Db", "LeaseStore");

ChangeFeedProcessor processor = source
.GetChangeFeedProcessorBuilder<Product>(
processorName: $"SyncProcessor-{Environment.MachineName}",
onChangesDelegate: HandleChangesAsync)
.WithInstanceName(Guid.NewGuid().ToString())
.WithLeaseContainer(leases)
.Build();

You need to ensure that the partition workload is dynamically distributed across all running replicas, and that each partition is leased and processed by exactly one instance at any given time.

Which modification should you make to resolve this issue?

  1. Set the `processorName` argument in `GetChangeFeedProcessorBuilder` to a constant string value shared by all host instances, and ensure the `LeaseStore` container is partitioned by `/id`.Answer
  2. B
    Set the `WithInstanceName` argument to a constant string value shared by all host instances, and keep the dynamic `processorName` argument.
  3. C
    Configure the `LeaseStore` container to be partitioned by `/productId` to match the source container's partition key, and keep the dynamic `processorName` argument.
  4. D
    Configure the `LeaseStore` container to be partitioned by `/SyncProcessor` to match the prefix of the dynamic processor name, and set `WithInstanceName` to a static value.

Answer

Set the processor name argument in the builder to a constant string value shared by all host instances, and ensure the lease container is partitioned by the ID property.
The correct answer resolves the issue by standardizing the processor name to a constant value across all running instances. In the Azure Cosmos DB Change Feed Processor SDK, the processor name defines the logical consumer group. Replicas sharing the same processor name will coordinate via the lease container to divide the partitions of the source container amongst themselves, ensuring each partition is processed by only one instance at a time. The lease container must also be partitioned by the ID property to function correctly.

Step-by-Step Solution

1
Analyze the role of the processor name parameter in the Change Feed Processor builder.
The processor name acts as a logical grouping (consumer group). Instances sharing the same processor name work together to distribute the change feed partitions.
Because the code uses a dynamic string containing `Environment.MachineName`, each host instance receives a unique processor name, making them separate consumer groups that all process the entire change feed.
2
Define a constant processor name across all instances.
Changing `$"SyncProcessor-{Environment.MachineName}"` to a constant string like `"SyncProcessor"` groups the replicas together.
This allows the Change Feed Processor load-balancing logic to distribute leases for the partitions among the replicas instead of duplicate processing.
3
Configure the lease container partitioning.
Confirm that the lease container is partitioned by `/id`.
The Azure Cosmos DB .NET SDK v3 requires the lease container to use `/id` as its partition key to successfully write and manage individual lease documents for each monitored partition.

Key Concept

Azure Cosmos DB Change Feed Processor Scaling and Lease Configuration
Rate this question

Topics

Process Azure Cosmos DB Change Feed Notifications

More questions from this topic