Examkin

Question

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

A financial reconciliation service logs credit card transactions to an Azure Cosmos DB Core (SQL) API container. Each document contains the following structure:

{
"transactionId": "d7bfa5d3-8b7a-47ef-b4b1-9f9fa82fb5a7",
"merchantId": "8f8c6e3b-5867-4e78-bc41-df0c0cf8ef23",
"transactionDate": "2026-07-16",
"amount": 120.50,
"status": "Pending"
}

The service has the following requirements:
- Ingestion: Handles up to 15,00015,000 write operations per second during peak hours.
- Transactional Boundary: A daily reconciliation process must use a `TransactionalBatch` to atomically update the status of all transactions for a single merchant on a specific day.
- Reads: Multiple independent reconciliation nodes must read and verify these daily merchant records.

You need to select a partitioning strategy that avoids hot partitions and satisfies the transactional requirements.

Which partitioning strategy should you implement?

  1. A
    Configure transactionId as the partition key.
  2. B
    Configure transactionDate as the partition key.
  3. Configure a synthetic partition key that concatenates the merchantId and transactionDate properties.Answer
  4. D
    Configure merchantId as the partition key and rely on Session consistency to guarantee read-your-writes visibility across all distributed reconciliation nodes.

Answer

Configure a synthetic partition key that concatenates the merchantId and transactionDate properties.
The correct answer is to use a synthetic partition key combining the merchant identifier and the transaction date. This ensures that all transactions for a specific merchant on any given day share the same partition key, placing them in the same logical partition. This configuration satisfies the transactional boundary required to execute a TransactionalBatch while distributing the overall write volume across many unique merchant-date combinations, preventing hot partitions.

Step-by-Step Solution

1
Identify the transactional boundaries.
All updates to transactions for a single merchant on a specific day must be executed within a single TransactionalBatch.
Cosmos DB restricts TransactionalBatch operations to items that share the exact same partition key value.
2
Evaluate the cardinality and write distribution of candidate partition keys.
Using transactionDate creates a hot partition on the current date, while using transactionId makes transactional batches impossible. Using merchantId alone can lead to unbounded partition growth over time for high-volume merchants.
A partition key must distribute throughput and storage evenly to prevent rate-limiting and exceeding physical partition limits.
3
Formulate a synthetic partition key solution.
Combining merchantId and transactionDate (e.g., merchantId_transactionDate) creates a key with high cardinality that groups all required documents for a merchant's daily batch into a single logical partition.
Synthetic partition keys allow developers to meet transactional boundaries without sacrificing partition key cardinality or causing hot partitions.

Key Concept

Configuring synthetic partition keys to satisfy transactional boundaries (TransactionalBatch) while preventing hot partitions under high-volume workloads.
Estimated Time:2m 0s
Rate this question

Topics

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

More questions from this topic