Common sharding strategies and choosing a shard key

package com.bank.sharding;

public class HashShardRouter {

    private final int shardCount;

    public HashShardRouter(int shardCount) {
        this.shardCount = shardCount;
    }

    public int getShard(String accountId) {
        int hash = Math.abs(accountId.hashCode());
        return hash % shardCount;
    }

    public static void main(String[] args) {
        HashShardRouter router = new HashShardRouter(4);
        System.out.println("SAV2001 → Shard " + router.getShard("SAV2001"));
        System.out.println("SAV2002 → Shard " + router.getShard("SAV2002"));
        System.out.println("SAV2003 → Shard " + router.getShard("SAV2003"));
        // Even distribution across 4 shards
    }
}

package com.bank.sharding;

import java.util.SortedMap;
import java.util.TreeMap;

public class ConsistentHashRouter {

    private final SortedMap<Integer, String> ring = new TreeMap<>();
    private final int virtualNodes;

    public ConsistentHashRouter(int virtualNodes) {
        this.virtualNodes = virtualNodes;
    }

    public void addShard(String shardName) {
        for (int i = 0; i < virtualNodes; i++) {
            int hash = (shardName + "-vn" + i).hashCode();
            ring.put(hash, shardName);
        }
    }

    public String getShard(String key) {
        int hash = key.hashCode();
        SortedMap<Integer, String> tail = ring.tailMap(hash);
        int nodeHash = tail.isEmpty() ? ring.firstKey() : tail.firstKey();
        return ring.get(nodeHash);
    }

    public static void main(String[] args) {
        ConsistentHashRouter router = new ConsistentHashRouter(100);
        router.addShard("shard-0");
        router.addShard("shard-1");
        router.addShard("shard-2");

        System.out.println("SAV2001 → " + router.getShard("SAV2001"));
        System.out.println("SAV2002 → " + router.getShard("SAV2002"));

        // Adding shard-3 moves only ~1/4 of keys, not all
        router.addShard("shard-3");
        System.out.println("After adding shard-3:");
        System.out.println("SAV2001 → " + router.getShard("SAV2001"));
    }
}

package com.bank.sharding;

public class RangeShardRouter {

    // Shard 0: account IDs A000000 - A999999
    // Shard 1: account IDs B000000 - B999999
    // Shard 2: account IDs C000000 - C999999

    public int getShard(String accountId) {
        char prefix = accountId.charAt(0);
        if (prefix <= 'A') return 0;
        if (prefix <= 'B') return 1;
        return 2;
    }

    // Risk: if all new accounts start with 'C',
    // Shard 2 becomes a hot spot
    // Monotonically increasing IDs always land on the last shard
}

package com.bank.sharding;

import java.util.HashMap;
import java.util.Map;

public class DirectoryShardRouter {

    // Lookup table: key → shard mapping
    private final Map<String, Integer> directory = new HashMap<>();

    public void registerAccount(String accountId, int shardId) {
        directory.put(accountId, shardId);
    }

    public int getShard(String accountId) {
        Integer shard = directory.get(accountId);
        if (shard == null) {
            throw new IllegalArgumentException("Unknown account: " + accountId);
        }
        return shard;
    }

    // Pros: can rebalance by changing the directory entry
    //       maximum flexibility in placement
    // Cons: extra lookup on every access
    //       directory must be highly available and cached
    //       directory itself can become a bottleneck

    public static void main(String[] args) {
        DirectoryShardRouter router = new DirectoryShardRouter();
        router.registerAccount("SAV2001", 0);
        router.registerAccount("SAV2002", 1);
        router.registerAccount("SAV2003", 0);  // Can place anywhere

        System.out.println("SAV2001 → Shard " + router.getShard("SAV2001"));
        System.out.println("SAV2002 → Shard " + router.getShard("SAV2002"));
    }
}

| Feature           | Hash-based          | Range-based        | Directory-based     |
|-------------------|---------------------|--------------------|---------------------|
| Distribution      | Even                | Depends on ranges  | Flexible            |
| Single-key lookup | Fast (compute hash) | Fast (find range)  | Lookup required     |
| Range queries     | Scatter-gather      | Efficient          | Lookup per key      |
| Hot spots         | Unlikely            | Likely (monotonic) | Controllable        |
| Adding shards     | Consistent hashing  | Add new range      | Update directory    |
| Rebalancing       | Move ~1/N keys      | Hard (split range) | Granular (per key)  |
| Complexity        | Low                 | Low                | Medium (directory)  |

package com.bank.sharding;

public class ShardKeyDecision {

    // Rule 1: High cardinality
    // GOOD: account_id (millions of unique values)
    // BAD:  branch_city (only 50 cities → uneven distribution)

    // Rule 2: Even distribution
    // GOOD: account_id with hash (spreads evenly)
    // BAD:  created_date (all current writes hit one shard)

    // Rule 3: Aligned with dominant query
    // Dominant query: "get all transactions for account SAV2001"
    // GOOD: shard by account_id → single shard hit
    // BAD:  shard by txn_date → scatter-gather across all shards

    // Rule 4: Avoid cross-shard joins
    // If accounts and transactions are on different shards,
    // joining them requires network calls between shards
    // GOOD: co-locate account + its transactions on the same shard

    // Rule 5: Very hard to change later
    // Model your query patterns BEFORE choosing the shard key
    // Re-sharding moves enormous amounts of data
}

-- WRONG: sharding by created_date sends all new rows to the latest shard
-- Hot spot: one shard handles all current writes

-- CORRECT: sharding by customer_id distributes writes evenly
-- Most queries filter by customer_id, so they stay shard-local
SELECT * FROM transactions
WHERE customer_id = 42 AND created_at > '2024-01-01';

Senior shard key checklist:
1. List all dominant query patterns
2. Pick the key that most queries filter on
3. Verify high cardinality and even distribution
4. Co-locate related data on the same shard
5. Use consistent hashing with virtual nodes
6. Plan resharding strategy from day one
7. Test with realistic data distribution before production