Question

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

A media streaming application stores user watch history in an Azure Cosmos DB Core (SQL) API container. The database must handle millions of active users who update their viewing progress every 30 seconds. The application must support transactional batch operations to update a user's viewing progress across multiple shows atomically. The most common query retrieves the complete viewing history for a single user to display on their dashboard.

Which partition key should you configure for the container to satisfy these requirements and avoid hot partitions?

  1. userIdAnswer
  2. B
    videoId
  3. C
    date
  4. D
    userId_videoId

Answer

userId
Selecting the user identifier is the correct choice. It provides high cardinality across millions of users, ensuring that data and throughput requests are evenly distributed across physical partitions. Furthermore, it colocates all viewing history for any single user within the same logical partition. This colocation makes the primary query for a user's dashboard a single-partition query and enables transactional batch operations, which require all involved documents to share the same partition key.

Step-by-Step Solution

1
Analyze the transactional boundary requirement.
Cosmos DB transactional batch operations are scoped to a single logical partition key. Therefore, the partition key must allow all related items to be updated together under the same key.
This rules out any keys that segment a single user's activities across different partitions, such as a synthetic user-video key.
2
Analyze the throughput and query profile.
Writes occur every 30 seconds per active user, and reads retrieve the complete watch history per user. Partitioning by user identifier groups a user's history into a single logical partition and scales out writes across millions of users.
This prevents hot partitions by using a key with extremely high cardinality.
3
Evaluate distractors for hot partition risks.
Partitioning by video identifier or date concentrates writes on popular media or the current day, creating hot partitions and resulting in rate-limiting.
Choosing a key with low cardinality or highly skewed write traffic violates partitioning best practices.

Key Concept

Selecting a partition key in Azure Cosmos DB to distribute workload and storage, while supporting transactional boundaries and preventing hot partitions.
Rate this question