Step through each strategy to see how a write is routed
Waiting...
Range-Based Sharding
Split data by value ranges (e.g., user IDs 1–1M on Shard A)
👤Client
↓
🔀Shard Router
↓
🗄️Shard AIDs 1–1M
🗄️Shard BIDs 1M–2M
🗄️Shard CIDs 2M+
1
Client sends a write for user_id = 750,000
2
Router checks range map: 1–1M → Shard A
3
Write routed directly to Shard A (O(1) lookup)
4
⚠ Hot-spot risk: if most active users are 1–1M, Shard A gets overloaded
5
✓ Great for range scans (e.g., "all orders between Jan–Mar"). Needs reshard plan for skew.
Routed Target
Processing
Overloaded
Migrating
Key Concepts
Critical insights every engineer should understand about sharding
Why Shard at All?
A single DB node has hard limits on storage, connections, and write throughput. Sharding horizontally scales the data tier by splitting the dataset across N independent nodes — each owns a fraction of the keyspace.
Rule of thumb: shard when single-node query latency degrades or storage exceeds 70% capacity
Cross-Shard Queries
Queries that span multiple shards require scatter-gather: fan out to all shards in parallel, then merge. This adds latency and complexity — good schema design minimises cross-shard joins.
Strategy: co-locate related data (user + orders) on the same shard using a tenant/user key
Rebalancing & Hotspots
Load skew happens when one shard receives far more traffic than others. Mitigation: consistent hashing with virtual nodes, or pre-splitting with range sharding. Plan for rebalancing from day one.