System Design · core
Unique ID Generation
Snowflake, ULID, and UUIDv7 — unique ids without a central allocator.
Mental model
A database sequence is a coordination point, so distributed id schemes buy independence by partitioning the id space: Snowflake spends bits on a timestamp, a machine id, and a per-millisecond counter, so two nodes cannot collide without sharing a machine id. Time-ordered prefixes are the second reason to care — random UUIDv4 keys scatter writes across a B-tree and destroy insert locality, whereas UUIDv7 and ULID sort by creation time and keep inserts at the right edge of the index.
How to study Unique ID Generation
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use the linked roadmap and primary implementation references to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Unique ID Generation with Sharding, Consistent Hashing. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Pack and unpack a Snowflake id and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
Primary keys at scale, idempotency keys, and any id generated before a write reaches the database.
Common mistakes
- Using random UUIDv4 as a clustered primary key, causing page splits and index fragmentation
- Ignoring clock skew and rollback — Snowflake ids collide or go backwards if the clock moves
- Leaking information: a sequential id exposes volume, and a timestamped one exposes creation time
- Assuming machine ids assign themselves; duplicated worker ids are the classic Snowflake outage
Learn from primary sources
Use the linked roadmap context and practice prompt.
Practice and explain it back
Pack and unpack a Snowflake id
Implement pack(timestampMs, machineId, sequence) and unpack(id) for a 64-bit Snowflake layout: 41 bits timestamp (ms since a custom epoch), 10 bits machine id, 12 bits sequence. Use BigInt. pack must throw when machineId or sequence exceeds its field.
Expected evidence: unpack(pack(1700000000000n, 42n, 7n)) -> { timestampMs: 1700000000000n, machineId: 42n, sequence: 7n }
Open the interactive drill →Review prompts
- Switching a primary key from random UUIDv4 to UUIDv7 improved write throughput without any schema change. Why?
Build evidence
Use a roadmap capstone to turn this concept into working evidence.