Unique ID Generation

One-liner: Pick IDs that are unique across nodes without coordination and, ideally, time-sortable: Snowflake-style 64-bit or UUIDv7/ULID.

Say this#

SAY THIS

Auto-increment (sequence) — DB-generated; simple, sortable; single point of coordination; leaks counts.
UUID v4 — 122 random bits; no coordination; not sortable; fragments B-tree indexes.
UUID v7 — 48-bit Unix ms timestamp + random; time-ordered; standardized (RFC 9562, 2024).
ULID — 48-bit timestamp + 80 random bits, 26-char Crockford base32; lexicographically sortable.
Snowflake (Twitter) — 64-bit: 1 sign + 41 timestamp ms + 10 machine + 12 sequence.
Ticket server (Flickr) — a dedicated MySQL with REPLACE INTO on an auto-increment; two servers with odd/even.
Range/batch allocation (Hi/Lo) — grab a block of IDs from a central store, hand out locally.
Clock skew / clock going backwards — Snowflake's failure mode; wait or refuse.
Machine ID assignment — static config, Zookeeper/etcd ephemeral nodes, or derived from IP/pod.
k-sortable / roughly time-ordered — sortable to within a few ms, not strictly.
Index locality — sequential IDs append to the right of the B-tree; random IDs splat across pages.
Enumeration attack — guessable sequential IDs expose /orders/1001; use random or encode.

How it works#

Snowflake layout (64 bits):

TEXT

| 0 | 41 bits: ms since custom epoch | 10 bits: worker id | 12 bits: sequence |      ~69 years                         1024 workers          4096 ids / ms / worker| 0 | 41 bits: ms since custom epoch | 10 bits: worker id | 12 bits: sequence |
      ~69 years                         1024 workers          4096 ids / ms / worker

Each worker gets a unique ID (config or Zookeeper).
On request: read clock; if same ms, increment sequence; if sequence overflows, spin to next ms.
If clock moved backwards: refuse or wait; alert.
Result: sortable, unique, 64-bit (fits BIGINT), no network call per ID.

Variants: Instagram (41 time + 13 shard + 10 seq, generated inside Postgres with a PL/pgSQL function), Sony Sonyflake (39 time in 10 ms + 8 seq + 16 machine), Discord snowflakes.

UUIDv7 layout: 48-bit ms timestamp | ver(4) | 12 rand | var(2) | 62 rand. Stored as 128-bit, string 36 chars.

Trade-offs#

Choice	Pro	Con
Auto-increment	Simple, compact, sortable	Single DB bottleneck; sharding needs offsets/step; predictable
UUID v4	No coordination, unguessable	128 bits; random index inserts hurt (InnoDB clustered PK especially)
UUID v7 / ULID	No coordination, sortable, index-friendly	128 bits; leaks creation time
Snowflake	64 bits, sortable, very fast, fits BIGINT	Needs worker-ID assignment and clock discipline
Ticket server	Works with legacy auto-increment code	Extra service; two-server trick limits scale
Hi/Lo blocks	Few round trips	Gaps; not time-ordered across nodes

Numbers#

Snowflake: 4096 IDs per ms per worker ≈ 4M IDs/s per worker; 1024 workers; 41-bit ms timestamp lasts ~69 years from epoch.
UUID: 128 bits; v4 has 122 random bits; collision probability negligible (~1 in 2^61 for 2^30 IDs).
ULID string 26 chars; UUID string 36 chars (32 hex + 4 dashes); BIGINT 8 bytes.
UUIDv7 timestamp resolution 1 ms; monotonic within a node via counter bits if implemented.

Say this#

How it works#

Trade-offs#

Numbers#

In the interview#