Choosing the Right Shard Key

The shard key is the single most important decision in your sharding design. A bad shard key can make your sharded database perform worse than a single server. A good one can scale you to millions of users.

What Makes a Good Shard Key?

A good shard key has four essential properties:

Property 1: High Cardinality

Low Cardinality (Bad):
  status: ["active", "inactive", "pending"]  // Only 3 values

High Cardinality (Good):
  user_id: [1, 2, 3, ... 100,000,000]  // Millions of values

Property 2: Even Distribution

High cardinality isn't enough. The values must also be evenly accessed.

Write Distribution vs Read Distribution

Consider both:

# User sign-ups (writes)
user_id: Even distribution ✓

# User activity (reads)
user_id: Uneven! Active users accessed 1000x more than dormant users

# Solution: Combine with hashing or accept some hotspots

Property 3: Query Alignment

Your shard key should match your most common queries. If queries don't include the shard key, you'll need to query all shards (scatter-gather).

# If shard key is user_id:

# GOOD: Query includes shard key - goes to one shard
SELECT * FROM orders WHERE user_id = 12345;

# BAD: Query doesn't include shard key - must query ALL shards
SELECT * FROM orders WHERE order_date = '2024-01-15';

Property 4: Immutability

The shard key value should never change. If it does, the record must move to a different shard.

# BAD: Mutable shard key
shard_key = user.country  # User moves from "US" to "UK"
# Now user's data needs to migrate from US shard to UK shard!

# GOOD: Immutable shard key
shard_key = user.id  # Never changes

Common Shard Key Patterns

Pattern 1: Entity ID

The most common pattern. Shard by the primary entity ID.

# E-commerce: Shard by user_id
orders = {
    "shard_key": "user_id",
    # All of a user's orders on same shard
}

# Messaging: Shard by conversation_id
messages = {
    "shard_key": "conversation_id",
    # All messages in a conversation together
}

Pattern 2: Compound Keys

Combine multiple fields for better distribution and query flexibility.

# Multi-tenant SaaS
shard_key = (tenant_id, user_id)

# Benefits:
# 1. Queries with tenant_id go to subset of shards
# 2. Queries with tenant_id + user_id go to single shard
# 3. Large tenants spread across multiple shards

-- MongoDB compound shard key
sh.shardCollection("db.users", { tenant_id: 1, user_id: 1 })

-- Queries that work efficiently:
{ tenant_id: "acme" }                    -- Subset of shards
{ tenant_id: "acme", user_id: "u123" }   -- Single shard

Pattern 3: Hashed ID

Hash the ID to ensure even distribution (especially for sequential IDs).

# Auto-increment IDs are sequential
user_id = 1, 2, 3, 4, 5...

# Hash them for even distribution
shard_key = hash(user_id)

# Now sequential IDs distribute randomly across shards
hash(1) % 4 = 2
hash(2) % 4 = 0
hash(3) % 4 = 3
hash(4) % 4 = 1

Anti-Patterns: What to Avoid

Real-World Case Study: Instagram

Instagram shards user data by user_id, but for the media table, they use a compound approach:

# Instagram-style ID generation
def generate_id(shard_id):
    timestamp = current_time_ms() - EPOCH
    sequence = get_next_sequence()

    # 41 bits timestamp | 13 bits shard | 10 bits sequence
    id = (timestamp << 23) | (shard_id << 10) | sequence
    return id

# ID: 1387262464000 encodes shard 42
# You can extract shard_id directly from any ID

Decision Framework

Use this checklist when selecting a shard key:

Key Takeaways

Next up: Rebalancing - What happens when you need to add or remove shards.