Sharding: range, hash and directory

Distributed systems Senior Python 3.13+ PostgreSQL 17+ Reviewed 31 Oct 2026 By Best Latest Apps

Pick the fix

A multi-tenant SaaS shards by order_id hash. Every tenant dashboard query now hits all 16 shards. Better shard key?

Optionstenant_id, with large tenants moved via a directorycreated_at rangeRandom shard per rowKeep order_id, add more shards

Hint 1 of 1

Which id does nearly every query include?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A tenant_id, with large tenants moved via a directory

Correct. Tenant queries stay on one shard; the directory handles the few giants.

The shard key should match how queries filter. Almost every query here is per tenant, so sharding by tenant_id keeps each on one shard; a directory moves the few huge tenants.

Why not the others?

B created_at range. Every new order lands on the newest shard.
C Random shard per row. Every query becomes scatter-gather.
D Keep order_id, add more shards. More shards make fan-out worse.

30-second answer

Pick a shard key that most queries include and that spreads load evenly, often the tenant or user id. Hash sharding spreads keys evenly but makes range scans across shards. Range sharding keeps ranges together, good for time series, but new writes can all hit the newest shard. A directory (lookup table) maps keys to shards explicitly and lets you move a big tenant alone. Queries without the shard key become scatter-gather.

Practise saying it · 40 s. No recording, just a timer

How do you pick a shard key?

Say your answer out loud, then check which of these points you covered:

In most queries
Even load
Hash vs range vs directory
Avoid cross-shard work
Plan for resharding

Deep dive

Cross-shard transactions and joins are expensive; design so most requests stay on one shard.

Resharding is the hard part: plan for many logical shards on fewer physical servers, so you move shards rather than split them.

Unique constraints and sequences only work per shard; use globally unique ids (UUIDv7, Snowflake-style ids).

Before sharding, try read replicas, partitioning a table, caching and archiving old data.

Common mistakes

Sharding by a monotonically increasing key with range sharding (all writes on one shard).
Choosing a key that one celebrity tenant dominates.
Sharding before measuring that a single node is truly the limit.

Senior take & follow-ups

Name the key criteria (in most queries, even spread), compare the three schemes, and mention resharding.

Follow-up questions

Think of your answer first, then open the hint.

How do you find all orders for a product if you shard by customer?
Show hint
A secondary index table sharded by product, kept in sync, or scatter-gather.
What's the benefit of 1,024 logical shards on 8 servers?
Show hint
Rebalancing moves whole logical shards; no key-level resharding.

Suggest a fix if something here is wrong or out of date.