Question 1

What problem does generating unique identifiers solve?

Accepted Answer

Every record needs an identity, and in a distributed system many processes create records at once. Ids must never collide, but they also leak information, take up space in URLs and indexes, and influence write performance. "Use a UUID" answers only the first question.

Question 2

How does generating unique identifiers work?

Accepted Answer

The main families, and what each implies: Central sequence (database SERIAL/identity). Compact, ordered, and the database guarantees uniqueness. But it is a single point of coordination, and sequential ids reveal volume and let anyone enumerate your resources (/links/1000, /links/1001…). Block allocation. Each server reserves a range (e.g. 10,000 ids) from a central counter and hands them out locally. Coordination drops by the block size; ids are unique but only roughly ordered, and a crashed server's unused block is skipped. Random ids (UUIDv4, or random base62 strings). No coordination at all, and unguessable if the randomness is cryptographic. Uniqueness is probabilistic: with n ids already issued from a space of size S, a new one collides with probability n/S, so short random ids need an insert-and-retry on the rare collision. Random ids also scatter B-tree inserts, which costs write performance on large tables. Time-ordered ids (Snowflake, ULID, UUIDv7). A timestamp prefix plus a machine id or randomness: unique without coordination, sortable by creation time, and index-friendly. They reveal creation time. Hashes of content. The same input always maps to the same id, which is useful for deduplication, but different inputs can collide once truncated, and identical inputs from different owners share an id whether you want that or not. Length is a budget: a base62 string of length k has 62^k values (7 characters ≈ 3.5 trillion). The question is never "can it collide?" but "how often, and what happens when it does?". The answer to the second should always be a unique constraint that turns a collision into a retry rather than corruption.

Question 3

What does generating unique identifiers assume?

Accepted Answer

A unique constraint backs every scheme, so even a 'can't happen' collision fails loudly rather than overwriting data. Random ids use a cryptographically secure generator when guessability matters.

Question 4

How does generating unique identifiers fail?

Accepted Answer

Enumeration: Sequential public ids let anyone walk through every resource or estimate your volume. Silent overwrite on collision: An upsert keyed on a colliding id replaces someone else's record. Clock-based ids going backwards: Time-ordered generators must handle clock adjustments, or they emit duplicates or out-of-order ids. Weak randomness: Math.random-style generators are predictable; ids meant to be unguessable are not.

Question 5

What are the alternatives to generating unique identifiers?

Accepted Answer

Natural keys: The entity already has a stable, unique identity (an email for accounts, an ISBN) that will never need to change. Composite keys: Uniqueness is only needed within a parent, such as (document_id, seq).

Scheme	How it stays unique	What it reveals
Auto-increment	One counter hands out numbers	How many you've made, and every other id
Random (UUIDv4, random base62)	The space is so large that repeats are rare	Nothing
Time-ordered (Snowflake, UUIDv7, ULID)	Timestamp plus machine id or randomness	When it was created
Hash of the content	The same content always gets the same id	That two records have the same content

Generating unique identifiers

Learn it

Quick reference

How it goes wrong

Instead, consider

In practice

It assumes

Explain it in your own words

Where you practise it

Further reading