Topic 8.4
Shard Key Selection
In one line
High cardinality, even distribution, and alignment with real queries — the three criteria.
Think of it like this
Deciding how to organize files in a filing cabinet. If you file everything by 'the month it was created', and everyone submits paperwork in December, one drawer becomes overstuffed while the rest sit empty. Picking a good filing rule prevents that.
Key ideas
- 01
Cardinality: few distinct values (country) → useless unless geography literally scopes traffic.
- 02
Distribution: the key must be roughly uniform under write load — user_id-hash beats 'month' when writes spike in one month.
- 03
Query alignment: the key must appear in (almost) every query — otherwise scatter-gather.
- 04
Composite keys can fix 'user_id alone' problems (e.g. shard by (user_id) but partition within shard by time).
- 05
The designer heuristic: write access is 90% of the decision; reads follow.
- 06
Second-guess rule: a 'hot' shard key (celebrity user, one huge tenant) produces the hot-partition problem (8.5).
Explain without notes
Why is 'createDate' a tempting but bad shard key for a viral video platform?
Practice
Score three candidate keys for a ride-hailing database against the three criteria.
Trade-offs
- ↔
Perfect query alignment and perfect write balance rarely coincide — pick the write-pattern key and accept the read cost.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I evaluate shard keys by cardinality, uniformity, and query alignment.