Module 4 — Scaling
Sharding & Partitioning
Split data across multiple databases when one machine can't hold it all.
1The Pizza Shop Analogy
Simple Analogy
One pizza shop handles 100 orders/day. But you get 1000 orders! Options:
Bigger Oven (Vertical)
Has limits. Can't make oven infinitely big.
More Shops (Sharding)
Shop A handles A-M addresses, Shop B handles N-Z. Each has own kitchen, staff, ingredients.
2Visual: How Sharding Works
Before Sharding: Single Database
10TB Database
Bottleneck!
↓ Apply Sharding ↓
After Sharding: Distributed Data
Shard 1
Users A-G
3TB
Shard 2
Users H-N
3.5TB
Shard 3
Users O-Z
3.5TB
3Sharding Strategies
1. Range-Based Sharding
Split by ranges of shard key. user_id 1-1M → shard 1, 1M-2M → shard 2
Shard 1
ID: 1 - 1M
Shard 2
ID: 1M - 2M
Shard 3
ID: 2M - 3M
✓ Range queries efficient (get users 500K-600K)
✓ Simple to understand and implement
✗ Hot spots (recent users all on latest shard)
✗ Uneven distribution over time
2. Hash-Based Sharding
Hash the shard key, mod by number of shards. Evenly distributes data.
user_id = 12345
↓
hash(12345) = 8472910
↓
8472910 % 4 = 2
↓
Route to Shard 2
✓ Even distribution (no hot spots)
✓ Works well for key lookups
✗ Range queries need all shards
✗ Adding shards = rehash everything
3. Directory-Based Sharding
Lookup table maps key → shard. Maximum flexibility.
Lookup
Service
Service
→
user_1 → Shard A
user_2 → Shard B
user_3 → Shard A
✓ Complete flexibility in placement
✓ Easy to rebalance
✗ Lookup service is SPOF
✗ Extra latency for lookups
5Challenges with Sharding
!
Cross-Shard Queries
Problem: Need data from multiple shards? Query all, merge results.
Solution: Design to minimize. Keep related data together. Use scatter-gather only when necessary.
Example: Get all orders for user_123 → Easy (same shard). Get all orders > $100 → Hard (query all shards).
!
Cross-Shard Transactions
Problem: Transaction spans multiple shards. No single database to guarantee ACID.
Solution: Design to avoid. Use saga pattern. Or accept eventual consistency.
Example: Transfer money between users on different shards requires distributed transaction.
!
Rebalancing / Resharding
Problem: Adding shards means moving data. Can be massive operation.
Solution: Use consistent hashing. Plan capacity ahead. Do during low traffic.
Example: Going from 4 to 8 shards with hash-based = move ~50% of data.
!
Hot Spots
Problem: One shard gets way more traffic than others.
Solution: Better shard key. Split hot shard further. Add caching layer.
Example: Celebrity's data on one shard, millions hitting it.
6Consistent Hashing
Regular hashing: add a shard = rehash everything (move ~100% data). Consistent hashing: add a shard = move only ~1/n data.
How Consistent Hashing Works
S1
S2
S3
S4
D
1. Imagine a ring of all possible hash values (0 to 2^32)
2. Place shards at positions on the ring
3. For a key: hash it, walk clockwise to first shard
4. Adding shard 5? Only data between S4 and S5 moves
Virtual Nodes
Place each physical shard multiple times on the ring (virtual nodes). 100 virtual nodes per shard gives better distribution and smoother rebalancing.
7Key Takeaways
1Sharding splits data across databases when one can't handle the load.
2Shard key is critical. Choose one in most queries. Hard to change later.
3Hash-based for even distribution, range-based for range queries.
4Cross-shard operations are expensive—design to minimize them.
5Consistent hashing minimizes data movement when adding/removing shards.
6Sharding adds significant complexity—delay until truly needed.