Design a distributed unique ID generator: system design interview question

How the interviewer opens it

“Design a service that generates globally unique, roughly time-ordered identifiers. It must support high throughput without a central bottleneck.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

ID format and service life
Scale
Request mix
Order
Latency
Consistency and availability
Durability
Retries and gaps
Failure conditions
Scope limits

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Allocate one ID or a batch of IDs
Prevent duplicate IDs across regions, crashes, and process restarts
Return roughly time-ordered IDs within a positive signed 64-bit integer
Support high throughput without shared coordination for each ID

Usually out of scope

Strict global order
Gap-free IDs
Exactly-once allocation across client retries
Storage of the business records that use the IDs

What interviewers ask about

ID size and order: A fixed 64-bit value must support the service life, the process count, the peak rate, and approximate time order.
Clock changes: Clock changes can repeat an earlier ID range or move IDs far outside the permitted time order.
Process restarts and region failures: A replacement and an old process can both remain active. Lease expiry alone does not prevent them from issuing the same ID.

Common mistakes

The design contacts one shared counter for every ID.
The design uses random 64-bit values without a collision bound.
The design resets the sequence after a clock retreat.
The design reuses a process identity after lease expiry without a rule for old owners.
The design promises strict global order and full availability during a region split.
The design ignores the bit limit or the batch request rate.

The bar by level

Mid-level (L4/E4): Defines a valid bit layout, API, and local allocation path. Handles concurrent requests, sequence exhaustion, and basic clock retreats. Explains how workers receive unique identities.
Senior (L5/E5): Proves safety across restarts and stale owners. Keeps coordination outside the per-ID path. Quantifies capacity and defines rejection behavior for unsafe clocks and partitions.
Staff (L6+/E6+): States invariants for each process incarnation and timestamp interval. Proves safety during pauses, replacements, and partitions. Balances reservation duration, recovery delay, spare slots, and regional availability.

Scope of a strong answer

Core requirements

Allocate one ID or a batch of IDs
Prevent duplicate IDs across regions, crashes, and process restarts
Return roughly time-ordered IDs within a positive signed 64-bit integer
Support high throughput without shared coordination for each ID

Usually out of scope

Strict global order
Gap-free IDs
Exactly-once allocation across client retries
Storage of the business records that use the IDs

What interviewers ask about

ID size and order

A fixed 64-bit value must support the service life, the process count, the peak rate, and approximate time order.

Clock changes

Clock changes can repeat an earlier ID range or move IDs far outside the permitted time order.

Process restarts and region failures

A replacement and an old process can both remain active. Lease expiry alone does not prevent them from issuing the same ID.

Common mistakes

The design contacts one shared counter for every ID.

The design uses random 64-bit values without a collision bound.

The design resets the sequence after a clock retreat.

The design reuses a process identity after lease expiry without a rule for old owners.

The design promises strict global order and full availability during a region split.

The design ignores the bit limit or the batch request rate.

The bar by level

Mid-level (L4/E4)

Defines a valid bit layout, API, and local allocation path. Handles concurrent requests, sequence exhaustion, and basic clock retreats. Explains how workers receive unique identities.

Senior (L5/E5)

Proves safety across restarts and stale owners. Keeps coordination outside the per-ID path. Quantifies capacity and defines rejection behavior for unsafe clocks and partitions.

Staff (L6+/E6+)

States invariants for each process incarnation and timestamp interval. Proves safety during pauses, replacements, and partitions. Balances reservation duration, recovery delay, spare slots, and regional availability.