Unique ID generation
Create IDs that never collide across many servers, sort by time, and need no central coordinator.
Why it's harder than it looks
On one database, an auto-increment column hands out 1, 2, 3. Once you have many databases (shards) or many servers creating records, two of them can hand out the same number. You need IDs that are unique without everyone asking one central counter, and ideally sortable by time.
The options
| Approach | Pros | Cons |
|---|---|---|
| Auto-increment (one DB) | Simple, small, ordered | Single point of coordination; reveals your volume |
| UUID v4 (random 128 bits) | No coordination at all | Large; random order makes database indexes slower; not time-sortable |
| UUID v7 / ULID | No coordination, sortable by time | 128 bits, bigger than a 64-bit integer |
| Snowflake (64 bits) | Compact, time-sortable, no coordination per ID | Each machine needs a unique machine ID; relies on clocks |
| Ticket server / ranges | Small sequential numbers | A central service hands out ID blocks; must be highly available |
Try it: Snowflake
Twitter's Snowflake packs a timestamp, a machine ID and a per-millisecond counter into one 64-bit number. Generate a few, including three in the same millisecond, and look at the bits.
Gotchas
- Clock going backwards (NTP adjustment) could create duplicates. Generators wait or refuse until the clock catches up.
- Machine IDs must be unique: assign them from config or a coordinator like ZooKeeper at startup.
- Sequential IDs in URLs let outsiders guess other records and estimate your volume. Use a separate random public ID if that matters.
In the interview
- Ask whether IDs must be time-sortable, how compact, and generated where.
- Default answers: Snowflake for 64-bit sortable IDs at scale; UUID v7 if 128 bits is fine.
- For a URL shortener, mention base62-encoding a unique number to get short codes.