One customer is 30% of your traffic. One shard is on fire. Now what?
Split the data across N nodes. Every scheme trades one pain for another.
Three acts:1. fire
2. schemes
3. pick
Act 1The Fire
The fire
Even by design. Skewed by workload.
The fix waits three slides down. Hash first, then salting.
Act 2Distributing the Load
Distributing the load
Same board, four moves. Every scheme is a trade.
sorted keys, grouped by range. Range scans are one seek.
hash the key, mod N. Load spreads. Scans die.
celebrity key floods one partition. Append a random suffix to spread the writes.
fixed-N partitions. Add a node, hand it a few whole partitions. No re-hash.
Takeaway
Hash spreads load. Range keeps scans cheap. Salting patches hot keys. Every scheme is a trade.
Act 3Pick Your Scheme
Pick your partitioning scheme.
01
Range
sorted keys, scan-friendly.
PICK WHENrange queries dominate · time-series with rolling windows.
STRUGGLES ATsequential keys (timestamps) → all writes on one partition.
EXAMPLESHBase, BigTable.
02
Hash
even load, no scans.
PICK WHENpoint lookups dominate · load must spread evenly.
STRUGGLES ATrange queries → scatter/gather across every partition.
EXAMPLESCassandra hash, DynamoDB.
03
Fixed-N partitions
even load · cheap rebalancing.
PICK WHENnodes come and go · you want to add capacity without downtime.
STRUGGLES ATrange queries (same as hash) · one hot key still needs salting.
EXAMPLESRiak, Elasticsearch, Couchbase.
Rebalancing is orthogonal: fixed-N is the default sane choice; dynamic (HBase, Mongo) splits as data grows; proportional-to-nodes (Cassandra) scales bins with the cluster.