15.7 How do you keep IDs and unique rules across shards?

At the exam centre: Each hall numbering answer sheets 1, 2, 3 gives you twenty "sheet 57"s. And the rule "no two students share a seat number" is easy inside one hall, but who checks it across halls?

In the system: Two things a single database gave you for free now need design:

1. Unique IDs: each shard's auto-increment would repeat. Use globally unique IDs: Snowflake-style IDs, UUID v7, or ID ranges per shard (Chapter 10). Putting the shard number inside the ID (as Instagram's scheme does) lets any service find a row's shard from its ID alone.
2. Unique constraints on a column that isn't the shard key, like "one account per email" when users are sharded by user ID. Two sign-ups with the same email could land on different shards, each seeing no conflict. Fixes:
   • A separate uniqueness table keyed by the unique value (email → user_id), itself sharded by email. Sign-up first claims the email there (an insert that fails if it exists), then creates the user. If the second step fails, release the claim.
   • Make that column the shard key, if it fits the queries.
   • A dedicated uniqueness service.
3. Transactions across shards (moving money between two users on different shards) need two-phase commit or a saga (Chapter 17). Design so most transactions stay inside one shard.

Memory code: "Every hall numbers its own sheets, so stamp the hall on the number, and check uniqueness in one shared register."

---