SYSTEM DESIGN · QUESTION 120
How would you design a distributed unique ID generator?
On this page
I would clarify uniqueness scope, ordering, size, and whether IDs may reveal timing. Options include UUIDs, allocated database sequences, or structured IDs combining timestamp, worker identity, and a local counter. A distributed design must prevent worker collisions, handle clock movement and counter exhaustion, and define persistence or coordination. The appropriate scheme balances uniqueness, ordering, size, and operational complexity.
LET'S MAKE IT SIMPLE
First, the idea in plain English
Multiple servers may need to create identifiers at the same time without asking one central service for every ID. A good scheme lets them create IDs independently while avoiding collisions. Some systems also want IDs that sort by creation time or stay compact.
A USEFUL COMPARISON
Picture it this way
Several offices can issue ticket numbers if each has a unique office code plus its own counter. If two offices share a code or their clocks move unexpectedly, identifiers can collide or sort incorrectly.
FOLLOW THE JOURNEY
Combine uniqueness sources or coordinate sequence allocation
Compare random IDs, central sequences, and structured worker/time identifiers.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Generation assumptions should have a correctness backstop.
A design selects UUID randomness, coordinated sequence allocation, or a structured ID from timestamp, worker ID, and counter, with collision and clock checks.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Generation assumptions should have a correctness backstop.
UNDER THE HOOD
How it works, step by step
Define guarantees
Specify uniqueness scope, ordering, length, and information exposure.
Why it matters: No ID scheme satisfies every requirement equally.
Choose generation method
Use random IDs, centralized allocation, or structured worker IDs.
Why it matters: Coordination and collision risk differ.
Handle failure cases
Protect worker identity, clock changes, and counter rollover.
Why it matters: Distributed generation must survive operational changes.
Validate at storage
Keep a uniqueness constraint or collision check where feasible.
Why it matters: Generation assumptions should have a correctness backstop.
OUTSIDE THE TEXTBOOK
A practical example
A multi-region service needs sortable record IDs without a central round trip. It assigns unique worker identifiers and combines them with time and a per-worker sequence. The service monitors clock rollback and sequence exhaustion, while database uniqueness constraints catch configuration mistakes.
GO A LITTLE DEEPER
Technical details that matter
- UUIDs simplify decentralized generation but are larger and may not sort chronologically depending on version.
- Snowflake-style IDs partition bits among timestamp, worker, and sequence; worker assignment and clock behavior are critical.
- Sequential IDs can expose volume or creation order and create write hotspots in some storage layouts.
MAKE A GOOD CHOICE
When is this useful?
- Generating keys across many service instances.
- Creating sortable event or record identifiers.
- Avoiding a central database sequence bottleneck.
A database sequence is simplest when one authoritative database already allocates IDs and throughput is sufficient.
WATCH OUT FOR
Common misunderstandings
- Assuming timestamps alone guarantee uniqueness.
- Reusing worker identifiers after restart without coordination.
- Ignoring that sequential IDs can reveal ordering or create hotspots.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Distributed schemes require careful worker identity and clock management.
- Random IDs increase key size and may reduce locality.
- No identifier format provides authorization or secrecy by itself.
WHAT TO REMEMBER
Key takeaways
- 1Clarify uniqueness, ordering, size, and privacy needs.
- 2Choose between coordination and decentralized generation deliberately.
- 3Guard worker collisions, clocks, counters, and storage uniqueness.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
Are UUIDs guaranteed unique?
They provide extremely low collision probability for suitable versions, not a mathematical guarantee; systems should still define uniqueness scope.
Why are clock rollback and worker IDs important?
Structured IDs often rely on both time and worker identity. Reusing an identity or moving time backward can produce collisions without safeguards.
SAY IT OUT LOUD
How to explain this in an interview
“I would first clarify uniqueness scope, ordering, ID size, and whether time leakage is acceptable. A database sequence is simple but centralized; UUIDs are decentralized but larger; structured IDs can be sortable but need safe worker assignment and clock handling. I would also enforce uniqueness at storage where possible and never treat an ID as authorization.”
Connect this question to the roadmap topic it supports.