A key is also a routing decision
A partition key groups and distributes data. It influences which data can be accessed together and how work is distributed.
This discussion focuses on Cosmos DB for NoSQL. Other APIs and product capabilities require their own checks.
Start from one application
Imagine a multi-tenant application where most requests retrieve a tenant's records. A tenant identifier may look natural as a partition key.
Now ask what happens when one tenant becomes much larger or busier than everyone else. A tidy logical model can still create a skewed workload.
Consider three dimensions
- Distribution: how evenly do data and traffic spread?
- Query routing: can important requests supply the relevant key?
- Growth: can one key accumulate a disproportionate amount of data?
Investigate the largest tenant, the busiest minute, and long-lived records. An average traffic estimate is not enough.
Know what a filter means
A query that includes the partition key can target the relevant partitioning scope. A query without it may need broader work.
Measure request-unit consumption for representative operations. Small differences repeated across a busy workload can matter.
Plan for change
Partitioning choices are expensive to revisit because changing the design can require moving data and updating application access.
Check current support for hierarchical partition keys and other relevant features rather than assuming one flat key is the only option.
Validate before committing
Build a sample that includes skewed tenants and realistic document sizes. Test the exact point reads, lists, writes, and cross-tenant reports you need.
Record service configuration and current limits with your results. This conceptual guide creates no billable resources; deployment labs should add a region-specific cost estimate and cleanup plan.