The problem
A bad shard key concentrates load on one shard and ruins the whole point.
The idea
Pick a key that spreads data and load evenly and matches your query patterns.
How it works
Good keys have high cardinality and even access (e.g. user_id). Avoid keys that create hotspots (e.g. "country" when one country dominates, or a timestamp that funnels all new writes to one shard).
The tradeoff
Optimizing for even distribution can hurt locality (related data spread across shards → cross-shard queries).
In the wild
Sharding tweets by user_id keeps a user's data together but makes "global trending" a cross-shard problem.
Deep dive
Flow
- List the top read and write queries before choosing the key.
- Pick a high-cardinality key that sends common operations to one shard.
- Add a routing layer so callers do not know shard locations.
- Plan the cross-shard path separately for global queries.
Watch for
- Timestamp keys create a moving hot shard.
- Country or status keys look tidy but split load poorly.
- Even data distribution can still produce uneven traffic.
Common trap
Say which query becomes harder after sharding; that shows you understand the bill.
Common questions
What problem does Choosing a shard key solve?
A bad shard key concentrates load on one shard and ruins the whole point.
How does Choosing a shard key work?
Good keys have high cardinality and even access (e.g. user_id). Avoid keys that create hotspots (e.g. "country" when one country dominates, or a timestamp that funnels all new writes to one shard).
What are the tradeoffs of Choosing a shard key?
Optimizing for even distribution can hurt locality (related data spread across shards → cross-shard queries).
Where is Choosing a shard key used in production?
Sharding tweets by user_id keeps a user's data together but makes "global trending" a cross-shard problem.