A collaboration product is sharding its database. Options are hash of message ID, hash of user ID, or workspace ID. Which and why?

What is being tested

Whether you choose a shard key from the access pattern rather than from distribution evenness, and whether you recognise a natural domain boundary when you see one.

Why workspace

Almost all activity in a collaboration product is contained within a workspace: channels, messages, members, files, search, permissions. Sharding on workspace means the overwhelming majority of queries route to a single shard and never fan out.

That yields three benefits at once:

• Performance. Single-shard queries, joins still work within a workspace, no scatter-gather.
• Isolation. One workspace's load spike or incident is contained. This is a real product property, not just an operational one.
• A natural unit for migration, residency and dedicated infrastructure. A large enterprise customer can be moved to their own hardware without changing the data model — which is a common enterprise sales requirement and normally an expensive retrofit.

The general rule: the best shard key is a boundary the business already has. If you have to invent one, you will fight it forever, because queries will keep crossing it.

Why the alternatives fail

Hash of message ID distributes perfectly and makes every meaningful query a fan-out. "Show me the last 50 messages in this channel" would query every shard and merge. The evenness is real and worthless, because distribution was never the binding constraint — locality was.

Hash of user ID is closer but wrong for this domain: a message belongs to a channel in a workspace, and users belong to many workspaces. Channel history would fan out across every member's shard. It would be the right key for a product whose primary access is "everything about one user".

Automatic sharding does not remove the decision; it relocates it. Distributed databases still require a partition key, and choosing it badly produces the same fan-out with less visibility into why.

The problem you must still solve

Workspace sizes follow a power law. One enterprise workspace may be larger than tens of thousands of small ones combined, so sharding by workspace distributes work by workspace size, and one shard carries a disproportionate load.

Mitigations, usually combined:

• A dedicated shard for the largest workspaces, which is simple and effective and doubles as a commercial product tier.
• Sub-sharding within a huge workspace on a secondary dimension queries already filter on, such as channel.
• A directory rather than a hash, so placement is a decision that can be revised as workspaces grow, rather than a calculation that cannot.

Monitor per-shard load, not aggregate — averages hide exactly this problem, showing a healthy mean while one shard is on fire.