Strategies
| Strategy | Good for | Risk |
|---|---|---|
Range (createdAt, alphabetical) | Range scans | Hot spot on the newest range |
| Hash | Even distribution | Range queries become scatter-gather |
| Directory / lookup (tenant → shard) | Moving big tenants individually | The lookup service is critical infrastructure |
| Consistent hashing | Adding/removing nodes moves only ~1/N of keys | Needs virtual nodes for balance |
Choosing a shard key
A good key has high cardinality, even write distribution, and is present in most queries (to avoid scatter-gather).
For multi-tenant SaaS, { tenantId, <something high-cardinality> } is the classic compound key. Queries stay tenant-local and big tenants still spread across chunks.
Pain points
- Hot keys (a celebrity user, one giant tenant): split the key, add a random suffix, or give that tenant a dedicated shard.
- Cross-shard transactions and joins are expensive. Design aggregates to live on one shard.
- Resharding is operationally heavy, so pick the key carefully. (MongoDB 5+ supports live resharding.)
Cheatsheet
The whole topic on one page. Click to open full screen.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
Replication
Keep copies of data on multiple nodes for availability, durability and read scaling — single-leader, multi-leader and leaderless, sync vs async.
MongoDB at Enterprise Scale
Data modelling by access pattern, indexing (ESR rule), transactions, change streams and the operational gotchas of large multi-tenant collections.
Multi-Tenant SaaS Architecture
Serve many customers from shared infrastructure while guaranteeing isolation of data, performance and configuration per tenant.