medium general · part of Practice Questions · Senior SWE Roadmap · topic form: Unique ID Generation (Distributed Systems)
Requirements to clarify
- Functional: generate a unique ID for every new record (order, message, user), across many machines, without a central bottleneck.
- Non-functional: uniqueness is mandatory, ideally roughly time-sortable (helps with DB index locality and natural chronological ordering), high throughput per node, no coordination required between nodes on the hot path.
Core components
See Unique ID Generation (Distributed Systems) for the concept.
- Snowflake-style composite ID: a 64-bit integer packed as [timestamp bits | datacenter/machine ID bits | per-millisecond sequence number bits] — each machine generates IDs independently and they’re globally unique by construction (different machine ID) and roughly time-ordered (timestamp is the high-order bits).
- Clock handling: since the timestamp is load-bearing, clock skew/rollback on a machine is the main risk — designs typically detect backward clock jumps and either wait or raise an error rather than risk generating a duplicate ID.
- Alternative: UUID: simplest (no coordination, no shared state at all) but not sortable and larger (128 bits) — fine when time-ordering doesn’t matter.
Key tradeoffs
- Snowflake-style IDs need each machine to have a unique, pre-assigned machine ID (a small coordination requirement at startup) in exchange for high-throughput, coordination-free generation afterward.