How do you choose a good shard key? What goes wrong with a poor one?

A good shard key has three properties:

• It has high cardinality: many different values.
• It spreads writes and data evenly across shards.
• It appears in most queries, so each query can go to just one shard.

Common mistakes:

• A low-cardinality key, like country. It creates a few huge shards that you cannot split further.
• A key that always grows, like a timestamp or an auto-increment id, with range sharding. Every new insert goes to the same last shard. This is a hot spot.
• A key that queries rarely filter on. Each query must ask every shard and combine the results. This is called scatter-gather, and it gets slower as you add shards.

For multi-tenant apps (one app serving many customer companies), tenant_id is often ideal. Almost every query includes it, and each tenant's data stays together. But one giant tenant can still overload its shard.

Hashing the key spreads writes evenly. But then range queries on that key must hit every shard. Changing the shard key later is expensive, so choose it from your real access patterns.