You are designing an Azure Cosmos DB container for a global financial clearing platform th… — Microsoft Azure Developer (AZ-204)

You are designing an Azure Cosmos DB container for a global financial clearing platform that processes credit card transactions. The workload has the following characteristics:

* Write Ingestion: The platform continuously ingests transaction records at a rate of $50,000$ transactions per second.
* Transactional Boundary: The platform uses the Azure Cosmos DB .NET SDK to execute `TransactionalBatch` operations. Each batch contains up to $100$ transaction updates for a single merchant account that must succeed or fail atomically.
* Read Query Pattern: Hourly reconciliation jobs query for all transactions executed for a specific merchant during a specific hour (e.g., querying for merchant `M_98765` between $10:00$ and $11:00$ UTC).
* Storage and Throughput Profile: A small number of high-volume merchants (such as global airlines and retail chains) generate over $45\%$ of the total transaction volume, while the remaining volume is distributed across millions of boutique merchants.

You need to select a partitioning strategy that supports the transactional batches, avoids logical partition size limits, and minimizes hot partitions.

Which partition key strategy should you select?

A synthetic partition key created by combining the merchant ID and the transaction hour (e.g., merchantId_yyyy-MM-dd-HH).Cevap
B
A partition key defined as the transaction ID (/transactionId).
C
A partition key defined as the merchant ID (/merchantId).
D
A synthetic partition key created by appending a random integer suffix between 1 and 10 to the merchant ID (e.g., merchantId_randomSuffix).

Cevap

A synthetic partition key created by combining the merchant ID and the transaction hour (e.g., merchantId_yyyy-MM-dd-HH).

The correct strategy is to use a synthetic partition key that combines the merchant ID and the transaction hour. This satisfies the transactional boundary since all transactions inside a batch belong to the same merchant and occur within the same hour, thus sharing the same partition key value. It also optimizes the hourly reconciliation queries by directing them to a single logical partition. Additionally, distributing a high-volume merchant's transactions across hourly partitions avoids exceeding the

20\text{ GB}

logical partition size limit.

Adım Adım Çözüm

Analyze the transactional boundary requirement.

Cosmos DB `TransactionalBatch` operations require all items in the batch to share the exact same partition key value.

This rules out partitioning strategies that separate transactions within the same batch, such as using the transaction ID or random suffixes on the merchant ID.

Evaluate the storage growth limits and hot partition risks.

A single logical partition in Azure Cosmos DB cannot exceed

20\text{ GB}

of storage.

Using the merchant ID alone as the partition key would cause high-volume merchants to exceed the storage limit and cause write rate-limiting due to hot partitions.

Analyze the read query optimization requirement.

Queries filtering by merchant and hour should target a single partition key to avoid cross-partition query overhead.

A synthetic key combining the merchant ID and the transaction hour ensures that all transactions for that hour are co-located in the same logical partition.

Select the partition key that satisfies all criteria.

The synthetic key `merchantId_yyyy-MM-dd-HH` is the optimal choice.

It preserves transactional boundaries for hourly batches, prevents any single partition from growing indefinitely, and optimizes hourly queries to a single logical partition.

Anahtar Kavram

Synthetic partition keys and partition boundaries in Azure Cosmos DB.

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru