Examkin

Question

Difficulty: HardProcess Azure Cosmos DB Change Feed Notifications

An e-commerce application uses an Azure Cosmos DB SQL API container named `Orders` partitioned by `/customerId`. You are implementing two new independent microservices:

* `OrderArchiver` to archive order documents to Azure Blob Storage.
* `InventoryUpdater` to update external inventory counts.

Both microservices will scale out across multiple host instances, and both are configured to use the same lease container named `leases`. During testing, you observe that when both microservices are running, each order event is processed by either `OrderArchiver` or `InventoryUpdater`, but never by both.

You need to ensure that all instances of both microservices process every event from the change feed.

What should you do?

  1. Configure each microservice to use a unique `processorName` when calling `GetChangeFeedProcessorBuilder`.Answer
  2. B
    Set the partition key of the `leases` container to `/customerId` to match the partition key of the `Orders` container.
  3. C
    Change the default consistency level of the Azure Cosmos DB client to Strong to guarantee that both processors read identical replicas.
  4. D
    Acquire a blob lease using the Azure Storage SDK to lock the lease container prior to starting each change feed processor instance.

Answer

Configure each microservice to use a unique `processorName` when calling `GetChangeFeedProcessorBuilder`.
The processor name parameter represents a logical group of instances (consumer group) that share the processing of the change feed. When two different workloads (like the archiver and inventory updater) share the same lease container and the same processor name, they are treated as a single consumer group. Consequently, the leases are distributed among all instances of both applications, causing each event to be processed by only one of them. Assigning a unique processor name to each microservice allows them to act as separate consumer groups, enabling both to receive a full copy of all change feed events.

Step-by-Step Solution

1
Identify the cause of the split events.
Since both microservices use the same lease container and the same default processor name, the SDK groups them together, load-balancing partition leases across all hosts of both services.
By default, the SDK treats instances with the same processor name as a single consumer group, splitting the events among them.
2
Understand consumer groups in Cosmos DB Change Feed.
Each independent functional workload must have its own logical name (processorName) so that the leases are partitioned separately.
This allows each consumer group to maintain its own checkpoint state and consume the full feed.
3
Assign a unique processorName to each microservice during builder initialization.
This creates separate leases in the lease container, allowing both microservices to consume every event.
Using separate processor names ensures that both the archiver and the inventory updater function as distinct consumer groups.

Key Concept

Cosmos DB Change Feed Processor Consumer Groups
Rate this question

Topics

Process Azure Cosmos DB Change Feed Notifications

More questions from this topic