Unique ID Generation

Overview

Distributed ID generation is the problem of handing out unique identifiers across many servers without a single bottleneck and, ideally, keeping them roughly time-sortable. It sounds trivial until you need billions of IDs per day, no collisions, no central chokepoint, and IDs that sort by creation time for efficient indexing.

🧠 Mental model: A single ticket counter at a deli hands out numbers in perfect order but jams when the line is long (one machine, one bottleneck). Distributed ID generation is like giving every counter its own numbered block so they never collide and customers can still tell who arrived first.

Key Concepts

The requirements are usually: globally unique, highly available, scalable (no single bottleneck), and often roughly time-ordered (k-sorted) so IDs cluster by time in the index.

UUID (v4) is random and generated locally with no coordination, so it never bottlenecks - but 128 bits is large and randomness scatters inserts across a B-tree, hurting locality. UUID v7 fixes the ordering problem by prefixing a millisecond timestamp, making it time-sortable.

Database auto-increment is simple and ordered but centralizes writes on one node. A ticket/segment server softens this: each app server reserves a range of IDs (say 1,000 at a time) and hands them out locally, contacting the DB only when the block runs out.

Snowflake is the canonical distributed scheme: pack a 64-bit integer from a timestamp, a machine ID, and a per-millisecond sequence counter. IDs are compact, sortable, and generated locally with no coordination.

Approach	Unique?	Sortable?	Bottleneck?	Notes
DB auto-increment	Yes	Yes	Single node	Simple; doesn't scale writes
UUID v4	Yes	No	None	128-bit, random, poor index locality
UUID v7	Yes	Yes	None	Timestamp-prefixed, index-friendly
Ticket/segment server	Yes	Roughly	Rare (block refill)	DB hit only per block
Snowflake (64-bit)	Yes	Yes	None	Needs machine-ID assignment + clock care

Machine IDs for Snowflake are typically assigned from a coordination service such as ZooKeeper, and the 41-bit timestamp ties this scheme directly to the clock concerns of distributed systems.

Trade-offs

The central tension is coordination vs. sortability vs. size. UUID v4 needs zero coordination but sacrifices ordering and index locality. Auto-increment gives perfect ordering but a hard write bottleneck. Snowflake threads the needle - local generation, compact, sortable - but reintroduces two operational hazards: assigning unique machine IDs and tolerating clock skew (a backward clock jump can produce duplicate IDs, so implementations must refuse to generate until time catches up). Ticket servers trade a small central dependency for simplicity and are often "good enough."

Interview Tips

Lead with "auto-increment is one node's bottleneck" to show you see the scaling problem immediately.
Reach for Snowflake when you need compact, sortable, locally generated IDs at scale - and mention clock skew.
Offer UUID v7 (or v4) when coordination-free simplicity beats compactness.
If asked why sortability matters, say it keeps time-adjacent rows together in the index, improving range scans and cache locality.

Summary

Distributed ID generation must be unique, available, and scalable, and is often time-sortable.
Auto-increment is simple and ordered but centralizes every write on one node.
UUID v4 is coordination-free but large and unordered; UUID v7 adds a time prefix for sortability.
Snowflake packs timestamp + machine ID + sequence into 64 bits for compact, sortable, local generation.
Watch for clock skew (backward jumps cause duplicates) and machine-ID assignment when using Snowflake.