# Choose a shard key
A bad shard key gives you jumbo chunks or a hot shard, and fixing it later means a reshard. Evaluate candidates on three axes:
## The three axes
1. Cardinality: how many distinct values? High cardinality lets MongoDB split into many chunks. Low-cardinality fields (status, region) cap how far you can scale.
2. Frequency: how often does one value repeat? A high-cardinality field where one value owns 80% of documents still creates a jumbo chunk.
3. Rate of change: is it monotonic (timestamps, ObjectIds, counters)? Monotonic keys send all new writes to the max-key chunk on one shard: the classic hot shard.
## Patterns
- Hashed shard key (`{ userId: "hashed" }`): spreads writes evenly, great for write scaling. Weak for range queries, since hashing destroys order.
- Ranged shard key on a high-cardinality, non-monotonic field: good for range queries and even distribution.
- Compound key (`{ tenantId: 1, createdAt: 1 }` style, or hashed prefix): isolates tenants and spreads within them. Match it to your actual query patterns so mongos can target shards.
## Rules
- Measure, do not guess: run distinct counts and top-value frequency analysis on production-shaped data.
- Never shard on a pure timestamp or ObjectId with a ranged key unless write volume is tiny.
- Remember the key is effectively immutable per document and changing it later requires resharding the collection.
## Verify
After sharding, watch chunk distribution and per-shard write load. Even spread under real traffic is the passing grade.