A hot partition is a logical partition that receives a disproportionate share of data or requests. In Azure Cosmos DB, that imbalance can make one partition a performance bottleneck even when other partitions have less work to do. section 11.3.3
The partition key determines where data belongs and helps Cosmos DB locate it for queries. Imagine an online store partitioned by product type: if the key has only a few values, the data may pile up unevenly. The same concern applies to request patterns—a partition that gets most of the traffic can become a hotspot. section 11.3.2 section 11.3.3
Choose a key with both distribution and the application's queries in mind:
- Prefer high cardinality: many distinct key values give data and requests more opportunities to spread out. Check peak workloads, not just the amount of stored data. section 11.3.2 section 11.3.3
- Match common access patterns. A region key may suit geographically diverse sales and queries filtered by region, but uneven regional sales could still concentrate load. section 11.3.2 section 11.3.3
- If one attribute is not enough, consider a composite key such as region–category. For time-dependent daily sales, a region–date key is another possibility. Choose an attribute that will not need updating after the key is set. section 11.3.2 section 11.3.3
There is a trade-off: a query spanning partitions can cost more request units and take longer. Favor keys that distribute the workload while letting common queries filter to the relevant partition. Automatic partition management does not remove the need to make that choice carefully. section 11.3.2 section 11.3.3
C:/> az cosmosdb mongodb collection create --account-name alpacacosmosdbaccount --database-name alpacacosmosdb --name alpacacontainer --resource-group AlpacaRG --shard "/region-category" --throughput 400
The Azure CLI example sets the collection's `--shard` path to `/region-category`, illustrating the proposed region–category partition-key choice. section 11.3.3
