Context
A MongoDB shard key influences where documents live and how requests find them. A key that spreads stored data evenly may still concentrate new writes or force common queries to contact many shards. Choose a candidate with both distribution and access patterns in view. The goal is a workable data-placement contract for the actual application.
Prerequisites
Collect server versions, collection size, representative query shapes, projected growth, write patterns, tenant sizes, and known seasonal changes. Obtain a test sharded environment or an approved analysis workflow. Keep sampled records protected and prefer aggregate evidence where possible. Review index and key restrictions for the installed MongoDB version before selecting an implementation procedure.
Compare candidate keys
- List the important operations and identify which candidate key fields each provides. Include point lookups, tenant-scoped lists, background scans, and write-heavy jobs. Explain queries in the test environment to observe routing. A query that omits useful shard-key information may require broader routing even when an ordinary index makes work inside each shard efficient.
- Measure candidate value distribution on representative data. Examine cardinality and the frequency of common values rather than using only the number of distinct values. A tenant field can have many values while one tenant still dominates demand. Consider skew in operations as well as skew in stored document counts.
- Review how new values arrive. A steadily increasing field can send new writes toward a limited active range under a ranged design. Hashing changes placement behavior and can change the suitability of range-oriented access. Compare these tradeoffs with the workload rather than treating either ranged or hashed sharding as a universal default.
- Rehearse the supporting index and migration prerequisites. Nonempty collections require the documented supporting-index preparation for initial sharding. Existing sharded collections need a supported refinement or resharding plan where appropriate, with storage, replication, and application validation included. A new key is a significant operational change, not simply another index to add during a busy incident.
Diagnostic table
| Evidence | Design concern | Next question |
|---|---|---|
| One value dominates requests | Hot value or tenant | Can the key divide that workload? |
| New writes hit a narrow range | Growing-key concentration | Would another distribution fit access? |
| Common queries contact all shards | Routing mismatch | Which useful key fields are available? |
| Data counts balance, latency does not | Workload skew differs | Where do expensive operations land? |
Illustrative scenario
A multi-tenant event service considers tenant ID alone. Most tenants are small, but one enterprise account generates a large share of new events. The team evaluates a candidate that can distribute that tenant's activity while preserving the most important tenant-scoped queries. It replays representative operations in a test cluster and records the routing tradeoff. This does not guarantee any particular throughput; it exposes the decision before migration.
Correct and verify
If a candidate creates broad routing or concentrated writes, revise the key or application access design before sharding. After a controlled rollout, compare per-shard workload, routing behavior, replication health, and latency under representative demand. Confirm that the application supplies the intended fields consistently. Storage balance alone is an incomplete acceptance criterion.
Operating procedure
Keep a shard-key decision record with workload samples, distribution observations, rejected tradeoffs, and expected growth. Review it when a large tenant joins or a new high-volume query appears. Monitor per-shard demand and routing changes alongside capacity. Define an escalation path for skew so operators can distinguish a design limitation from a temporary imbalance or an unhealthy shard.
Explore Clouvenix database administration for implementation and operational handover.