Design a distributed unique ID generator.

Summary

Generate 64-bit, roughly time-ordered IDs without coordination using the Snowflake layout (timestamp + machine ID + per-millisecond sequence), assigning machine IDs at startup and handling clock drift.

Requirements

• Unique across many nodes
• Roughly sortable by time
• High throughput (100K+/s per node), low latency
• 64-bit for DB friendliness

API

next_id() → 1849204391029383168

Data Model

bits: 1 unused | 41 ms timestamp (custom epoch, ~69 years) | 10 machine id | 12 sequence (4096/ms)

Architecture

Each service instance (or an ID service) gets a machine ID from configuration, a coordinator (ZooKeeper/etcd lease) or a database row. IDs are generated in process: the current milliseconds since a custom epoch, the machine ID, and a sequence that resets each millisecond; if the sequence overflows, wait for the next millisecond.

Deep Dives

• Clock moving backwards: refuse or wait until the clock catches up; monitor NTP
• Alternatives: UUIDv7 (128-bit, time-ordered, no coordination), DB sequences with range allocation, ULID
• Predictability: sequential IDs leak volume; don't use as secrets

Scaling

• No coordination per ID; scales linearly
• 1,024 machine IDs per layout; adjust bits as needed

Comparison / Tradeoffs

What interviewers look for

A structured approach: clarify requirements and scale, sketch the API and data model, draw the high-level architecture, then go deep on the hardest component and discuss trade-offs, bottlenecks and failure modes.

Follow-up questions

• When would you choose UUIDv7 instead?