Sharding & Partitioning

Splitting one dataset across many machines, and what the split costs you.

Range partitioning keeps ordering and invites hot spots; hashing kills both.

rangehashhot spotsscans

Try it

Move the dials — the sentence under the picture changes.

Partitioning

Key skewuniform ids

600 keys · 6 shards

With evenly spread ids, range partitioning distributes fine and keeps keys ordered, so a scan for “everything between X and Y” touches one shard. Raise the key skew to see what a monotonic id does to it.

What it is

Sharding splits one logical dataset across many machines so that no single machine has to hold it all or serve it all. The split rule is the entire design, because it decides both how evenly load lands and which queries remain possible.

Range partitioning

Assign contiguous ranges of the key to each shard: A-F here, G-M there. Keys stay in order, so a range scan — "every order between March and April" — touches one or two shards instead of all of them. Splitting a shard that has grown too large is a local operation.

The failure mode is severe and extremely common: if the key is monotonic (always increasing) — a timestamp or an auto-increment id — then every new write lands on the last shard. You have built a distributed system in which one machine does all the work and the rest hold archives. Turn the skew slider up in the widget to watch it happen.

Hash partitioning

Hash the key and use that to place it. Distribution stays flat regardless of what the keys look like, which is exactly what the range scheme could not promise.

The cost is that ordering is gone, deliberately. Adjacent keys are scattered, so any range query becomes a scatter-gather — ask every shard, merge the answers — and pays the latency of the slowest one. If range scans are a core access pattern, hashing has just made your main query the expensive one.

Directory partitioning

Keep an explicit lookup table of key to shard. Maximum flexibility — you can move one noisy tenant (customer) to its own shard — at the cost of a lookup on every request and a table that is now a critical dependency.

Choosing the shard key

This is the decision you cannot cheaply undo. A good key spreads writes, keeps the queries you actually run on a single shard, and does not concentrate one tenant's data in a way that makes them a hot spot. Those goals conflict, which is why the answer depends on the access pattern rather than on the data.

Compound keys are the usual escape: hash a prefix with many distinct values (a customer id) for distribution, then keep order within it (by time) so one customer's range queries stay on one shard.

Where it goes wrong

Cross-shard joins and transactions. Two keys can live on disjoint shards, so there is no cheap atomic operation across them.
Resharding. Changing the scheme means moving data while still serving traffic. Consistent hashing exists to make this survivable.
Hot tenants. An even distribution of keys is not an even distribution of activity. One customer can be larger than everyone else combined.

Take this with you

The one idea: the shard key decides both how evenly load lands and which queries stay cheap, and it is very hard to change later.
In an interview, contrast range vs hash, show the monotonic-key trap, and propose a compound key that fits the main query.
At work, look at your biggest customer. If their data is one shard, that shard is your ceiling.