A product must shard its primary data store. Which sharding pattern fits, and which decision is irreversible?

The irreversible decision

The shard key. Everything else — shard count, routing mechanism, rebalancing strategy, tooling — can change later with effort. Changing the key means rewriting the entire dataset while the product is live.

Why the isolation boundary beats even distribution

Choose the key that matches how the product actually queries and isolates — a workspace, a tenant, a merchant — rather than the one with the best distribution.

Even distribution is the least important property of a shard key. A perfectly distributed key that does not match the access pattern turns every ordinary query into a scatter-gather across every shard, which is slower than the unsharded system and far harder to operate.

Matching the isolation boundary gives: single-shard queries for the dominant access patterns, authorisation that never crosses shards, per-tenant export, deletion and migration for free, and a blast radius that is a set of customers rather than a random slice of every customer.

Why lookup-based routing over hashing

The cost of the isolation boundary is uneven distribution — tenants range from one person to tens of thousands. A routing table rather than a hash function is what makes that survivable: a single oversized tenant can be relocated without touching anything else, whereas modular hashing remaps almost everything when the node count changes.

Consistent hashing improves on modular hashing and still does not permit relocating one specific key deliberately, which is the operation you need most.

The supporting decisions

• More logical shards than physical databases, so growth is a remapping rather than a resharding.
• Composite keys where partitions would otherwise be unbounded — adding a time dimension bounds growth regardless of activity.
• A plan for hot keys, since no key choice prevents skew in the workload itself.
• Double-write migration with verification and per-tenant read cutover, so the blast radius of a mistake is one customer.

What gets harder afterwards

Cross-shard features need a separately-fed aggregated store. Schema migrations run N times with partial-failure states. Transactions do not span shards. And a very large single tenant eventually exceeds one shard, requiring a second-level split — which is why the routing table matters more than the hash function.