Generating Unique IDs at Scale

Every database you've used so far in this course has had one instance handing out IDs, trivial with auto-increment. That assumption is about to break: the rest of this module is about splitting data across multiple database instances, and the moment there is more than one instance, "just increment a counter" no longer works, because two instances would each hand out their own 1, 2, 3... with no coordination between them.

If Shard A and Shard B both auto-increment independently, they will both eventually assign id=482 to two completely different records. You need IDs that are unique across the whole system, not just within one database instance.

A UUID is a 128-bit random (or pseudo-random) value, collision-probability so low it's treated as impossible in practice. Any machine can generate one with zero coordination with any other machine. The cost: UUIDs are large (compared to a 64-bit integer), and the common random variant (v4) has no inherent ordering; you can't tell which of two UUIDs was created first just by looking at them.

Twitter's Snowflake approach (since adopted widely, including by Discord) packs a timestamp, a machine/worker identifier, and a per-millisecond sequence number into a single 64-bit integer. The result is compact like a normal integer, globally unique without central coordination, and, critically, sortable by creation time just by comparing the numbers, since the timestamp is the leading bits.