Atlas: choose a shard key using cardinality, frequency, and monotonicity

# 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.