Examkin

Question

Difficulty: MediumConfigure Partition Keys and Partitioning Strategies in Azure Cosmos DB

A logistics company is designing an Azure Cosmos DB for NoSQL database to track inventory movements across 15 high-volume regional warehouses. The system has the following requirements:

* Each warehouse processes up to 100,000 inventory transaction logs per day.
* To maintain inventory accuracy, the system must use the Azure Cosmos DB SDK's TransactionalBatch to perform atomic, multi-document updates (such as deducting stock from one bin and adding it to another) within a warehouse context.
* While the write throughput is extremely high and distributed across the warehouses, business analysts run daily reporting queries to analyze the complete historical data of a single warehouse, which requires scanning months of logs.
* The design must prevent logical partitions from exceeding the 20 GB storage limit while maintaining transactional integrity.

Which two of the following strategies should you implement to satisfy these requirements?

  1. Create a synthetic partition key by concatenating the warehouse identifier and the current date (e.g., warehouseId_YYYY-MM-DD).Answer
  2. Execute operations that must succeed or fail atomically using the SDK's TransactionalBatch class, targeting the same synthetic partition key value.Answer
  3. C
    Use the warehouse identifier (warehouseId) alone as the partition key to ensure that all historical queries for a warehouse are single-partition reads.
  4. D
    Append a random number suffix to the warehouse identifier (e.g., warehouseId_1 to warehouseId_10) to distribute writes more evenly across logical partitions.

Answer

Create a synthetic partition key by concatenating the warehouse identifier and the current date (e.g., warehouseId_YYYY-MM-DD), and execute operations that must succeed or fail atomically using the SDK's TransactionalBatch class targeting the same synthetic partition key value.
The correct strategy combines a synthetic partition key (the warehouse identifier and the current date) with TransactionalBatch. This ensures that atomic transactions (like transferring stock between bins) can be executed using TransactionalBatch because the items share the same logical partition. Furthermore, partitioning by date prevents any single warehouse's logical partition from growing indefinitely beyond the 20 GB limit.

Step-by-Step Solution

1
Analyze partition size constraints and transaction boundaries.
Identify that using a simple warehouse identifier partition key will cause the 20 GB logical partition limit to be exceeded over time, while a random suffix will break the transactional boundary needed for TransactionalBatch.
Azure Cosmos DB has a strict limit of 20 GB per logical partition, and TransactionalBatch operations are limited to a single logical partition.
2
Select a partition key strategy that balances write distribution and transactional scoping.
Choose a synthetic key that combines the warehouse identifier and a time window (e.g., warehouseId_YYYY-MM-DD).
This groups related daily operations within the same logical partition for transactions while preventing individual partitions from growing indefinitely.
3
Design SDK operations using the transaction scope.
Use TransactionalBatch for atomic writes, ensuring all operations in the batch point to the same synthetic partition key.
This guarantees transactional execution across the items sharing that synthetic key.

Key Concept

Azure Cosmos DB logical partition limits and transactional scopes
Rate this question

Topics

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

More questions from this topic