Examkin

Question

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

A gaming company is developing an Azure Cosmos DB database to support a new multiplayer battle arena game. The workload has the following profiles:

- Write profile: Approximately 50,00050,000 writes per second during peak hours to update active match telemetry and state.
- Read profile: Low-latency point reads to fetch the active state of a specific match.
- Transactional boundary: Multiple documents within a single match—specifically the session state document and individual player statistics—must be updated atomically using a Transactional Batch.

The document properties include:
- `gameSessionId`: A unique GUID identifying each match (high cardinality, thousands of concurrent sessions).
- `playerId`: A unique GUID identifying each player (high cardinality).
- `region`: The geographic region of the game server (low cardinality, e.g., 'US-West', 'EU-Central').
- `sessionDate`: The date of the session (e.g., '2026-07-16').

Which partition key should you choose for the container?

  1. A
    playerId
  2. B
    region
  3. gameSessionIdAnswer
  4. D
    sessionDate

Answer

The partition key should be gameSessionId.
Selecting gameSessionId as the partition key is the correct strategy. In Azure Cosmos DB, all operations in a Transactional Batch must share the same partition key value. Because the transaction needs to atomically update the session state and the stats of all players within a specific match, grouping these records under a shared gameSessionId satisfies this transactional requirement. Additionally, since there are thousands of concurrent sessions, gameSessionId has high cardinality, which distributes storage and the write workload of 50,00050,000 writes per second evenly across physical partitions, preventing the hot partition problem.

Step-by-Step Solution

1
Analyze the transactional boundary requirements.
Cosmos DB requires all operations in a Transactional Batch to target the same logical partition key.
This rules out partitioning by playerId, because a game session involves multiple players whose documents would reside in different partitions.
2
Evaluate fields for cardinality and write distribution.
region and sessionDate have very low cardinality, which concentrates 50,00050,000 writes per second on a subset of physical partitions.
Even throughput distribution is required to avoid hot partitions and rate-limiting (HTTP 429429 errors).
3
Select the key that satisfies both transaction and scaling requirements.
gameSessionId has high cardinality and groups all documents (session status and player stats) for a single match together.
This allows transactional batches to succeed while ensuring even write distribution across physical partitions.

Key Concept

Selecting a partition key in Azure Cosmos DB to align with transaction boundaries and maintain high cardinality to prevent hot partitions.
Estimated Time:1m 30s
Rate this question

Topics

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

More questions from this topic