Examkin

Question

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

An online multiplayer gaming platform stores active player session state and shopping cart data in an Azure Cosmos DB for NoSQL container. The platform experiences a high volume of writes (30,00030,000 operations per second) from players globally. Each document in the container has the following structure:

{
"sessionId": "a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d",
"playerId": "p9o8i7u6-y5t4-r3e2-w1q0-l9k8j7h6g5f4",
"region": "US-East",
"cartItems": [ { "itemId": "item-993", "quantity": 1 } ],
"lastUpdated": 1781568000
}

The application has the following operational requirements:
- Query transactions must update multiple session and cart documents for a single player within the same region atomically using transactional batches.
- Read queries must retrieve session history for a specific player in a given region with the lowest possible Request Unit (RURU) consumption.
- The partitioning strategy must distribute throughput and storage demand evenly to prevent hot partitions.

Which two actions should you take to design and implement this partitioning strategy? (Select two.)

  1. Create a synthetic partition key by concatenating the playerId and region properties (e.g., playerId_region), and set this as the partition key of the container.Answer
  2. Include the concatenated value of playerId and region in the filter clause of all read queries retrieving session history.Answer
  3. C
    Set region as the container's partition key to automatically group all regional player sessions.
  4. D
    Set playerId as the partition key and append a random number suffix from 11 to 55 to the partition key value for each write operation.
  5. E
    Configure the client application to use session consistency to automatically route single-player queries without specifying the region.

Answer

Create a synthetic partition key by concatenating the playerId and region properties, and ensure that all read queries for session history include this concatenated value in their filters.
To satisfy the transactional requirements, the partition key must encompass the transaction boundary, meaning all documents updated together (for a single player in a region) must share the same partition key. Combining the player ID and the region creates a synthetic key with high cardinality, distributing the workload evenly. To keep read query RU costs low, queries must target a single logical partition by including the synthetic partition key value in the filter.

Step-by-Step Solution

1
Determine the transactional boundary requirement.
Since multiple documents for a single player in a single region must be modified atomically in a transactional batch, they must reside within the same logical partition. Therefore, the partition key must contain both playerId and region.
Transactional batches in Azure Cosmos DB are scoped to a single logical partition.
2
Address the hot partition risk for write throughput.
Using playerId or region alone is insufficient; region has low cardinality, and playerId alone might not distribute the load if specific players have highly frequent sessions. A synthetic key combining playerId and region provides high cardinality with thousands of unique values.
High cardinality partition keys distribute storage and throughput (RUs) evenly across physical partitions.
3
Optimize query routing for read operations.
Ensure that the client query includes the partition key filter (playerId_region) to target a single logical partition.
Queries that do not filter on the partition key run as cross-partition queries, which consume significantly more RUs.

Key Concept

Synthetic partition keys and single-partition query routing in Azure Cosmos DB
Rate this question

Topics

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

More questions from this topic