Design a Unique ID Generator: System Design Interview 2026

Unique IDs sit beneath orders, payments, messages, jobs, and URLs. The design choice affects database locality, offline creation, information leakage, pagination, clock operations, and incident recovery. The right starting question is not “how do I implement Snowflake?” but what uniqueness, ordering, width, opacity, and lifetime does this identifier need?

This walkthrough assumes the 6-step system design framework and applies it at senior depth. It is Part 13 of an extended system design series.

Table of Contents

1. The Problem
2. Step 1 - Clarify Requirements
3. Step 2 - Compare ID Families
4. Step 3 - Size the Bit Budget
5. Step 4 - High-Level Design
6. Step 5 - Worker Ownership, Clocks, and Restarts
7. Step 6 - Operations, Regions, and Migration
8. Reference Architecture
9. Common Interview Mistakes
10. Quick Reference
11. Sources
12. Frequently Asked Questions
13. Related Articles

The Problem

Generate identifiers that are unique in a defined namespace and remain valid for a defined lifetime. Useful secondary properties may include compactness, approximate time order, decentralized generation, interoperability, or unpredictability.

These properties are different:

• uniqueness prevents two objects from receiving the same ID;
• monotonicity orders IDs within a stated scope;
• time ordering makes values roughly follow creation time;
• unguessability makes enumeration harder but is never authorization;
• idempotency maps a retry to the same operation and is not created automatically by minting another unique ID.

A database uniqueness constraint can detect a collision in that database, but IDs often cross logs, queues, and several stores. The generator's invariants still matter.

Step 1 - Clarify Requirements

Ask:

• What is the uniqueness scope: one table, tenant, environment, region, or the whole company?
• How many generator processes may be active, and what is the burst per process?
• Must creation work offline or during control-plane outage?
• Is ordering local, approximate across nodes, or globally strict?
• Can the ID reveal creation time, volume, region, or worker topology?
• Must it fit signed BIGINT, interoperate with UUID tooling, or travel through JavaScript/JSON?
• What happens after epoch exhaustion or a layout change?
• May consumers parse fields, or must the value remain opaque?

For public resources, do not rely on a sequential or random ID as an access-control token. Use authorization on every lookup. When revealing creation time or volume is unacceptable, expose a separate opaque public identifier.

Non-functional requirements

• Zero accepted duplicates within the declared scope.
• Bounded behavior for clock rollback, sequence exhaustion, worker loss, restart, and partition.
• No silent minting after worker ownership becomes uncertain.
• A published serialization contract across languages and databases.
• A migration plan before timestamp, worker, or sequence space is exhausted.

Step 2 - Compare ID Families

RFC 9562 standardized UUIDv7 in 2024. It stores a 48-bit Unix-millisecond timestamp first and uses the remaining 74 non-version/non-variant bits for randomness, optionally combined with a sub-millisecond fraction and counter. When 128 bits are acceptable, UUIDv7 removes the need to allocate a globally unique small worker ID and is often the lower-operations default.

UUIDv4 is not “bad for every database.” Random insertion can reduce locality in B-tree-style indexes, while the impact depends on engine, primary-key layout, write pattern, and workload. Benchmark the actual schema.

Snowflake is justified when 64-bit width, local ordering, or storage/index density materially matters enough to own its operational invariants.

Step 3 - Size the Bit Budget

The classic Twitter-style shape uses one nonnegative sign bit and 63 payload bits:

flowchart LR
    S["1 sign bit<br/>zero"] --- T["41 timestamp bits<br/>milliseconds"] --- W["10 datacenter and worker bits"] --- Q["12 sequence bits"]

Figure 1. The familiar 41/10/12 layout is one historical choice, not a universal Snowflake standard.

With a custom epoch:

• 2^41 milliseconds cover about 69.7 years;
• 10 worker bits encode 1,024 simultaneous namespaces;
• 12 sequence bits encode 4,096 values per worker per timestamp.

Those are representational limits, not achieved throughput. CPU, synchronization, clock reads, batching, contention, pauses, and backpressure determine sustainable rate. 4,096 × 1,000 is only the mathematical maximum sequence budget per second if every millisecond is fully used.

Model peak rate per worker, generator count including failover headroom, environment and region namespaces, clock precision, and epoch lifetime. A 10-bit worker field can disappear quickly if every application pod needs a unique value.

Serialization contract

Specify signedness, endianness, decimal/text representation, and database column type. A 64-bit Snowflake value exceeds JavaScript's safe integer range, so JSON APIs should usually transmit it as a decimal string and clients should use string or BigInt deliberately. Never allow a floating-point conversion to round two IDs to the same value.

Treat IDs as opaque in application code. Centralize optional decoding for operations; arbitrary consumers that infer timestamp or region make future layout migration much harder.

Step 4 - High-Level Design

flowchart TD
    Alloc[(Worker namespace allocator)] -->|assignment, incarnation, policy| Agent[Generator ownership agent]
    Agent -->|only while ownership is valid| Gen[Serialized local generator]
    Epoch[Epoch wall time] --> Gen
    Mono[Process monotonic elapsed time] --> Gen
    State[(High-water and restart state)] --> Gen
    Gen --> ID[64-bit identifier]
    Gen --> Metrics[Clock, sequence, and ownership metrics]

Figure 2. Hot-path generation can be local, but safe startup, ownership, and restart state are explicit dependencies rather than hand-waved away.

The generator may be a library, sidecar, or service:

• a library removes a network hop but multiplies worker namespaces and language implementations;
• a sidecar or node daemon shares one serialized generator across local processes;
• a service centralizes invariants and batching but adds network availability and latency.

Pick the boundary from deployment scale and failure ownership. “No network per ID” is valuable only if the local implementation is actually safe across threads, processes, forks, and restarts.

Step 5 - Worker Ownership, Clocks, and Restarts

The local tuple

A Snowflake-style ID is unique when no generated tuple repeats:

(timestampTick, workerNamespace, sequence)

Therefore all four conditions matter:

1. One active generator owns a worker namespace or distinct incarnation.
2. Calls sharing that namespace serialize timestamp and sequence state.
3. A used timestamp never restarts its sequence from zero for that namespace.
4. Layout, epoch, and namespace scope remain consistent across environments.

The packing expression cannot repair a violation of these conditions.

Why a lease alone is unsafe

A coordination service can allocate worker IDs, but a lease expiry does not stop an old process from computing IDs. etcd's own documentation explicitly notes that leases alone do not guarantee mutual exclusion for an external resource; the protected resource must validate a fencing version.

Snowflake's local hot path cannot ask every downstream store to validate a lease revision. Safe strategies include:

• non-reused worker assignments for the layout's lifetime;
• an incarnation field encoded into the namespace budget;
• infrastructure that provably terminates or fences the old generator before reuse;
• a durable high-water mark plus quarantine/startup protocol that guarantees the new owner begins beyond any tuple the previous owner could have issued.

The generator must stop before its locally known ownership validity expires and whenever renewal is ambiguous. Static IDs can be safe with strong deployment inventory, but duplicate configuration must fail before serving.

Clock sources

The encoded timestamp needs a common epoch, normally derived from wall time. Linux CLOCK_MONOTONIC measures time since an unspecified point related to boot; it does not provide Unix or custom-epoch time and does not survive reboot as the same timeline. It can measure elapsed time and protect an anchored logical clock during one process incarnation, but it is not a drop-in Snowflake timestamp.

A robust generator uses:

• epoch wall time to establish the timestamp domain;
• serialized lastIssuedTimestamp and sequence state;
• a monotonic elapsed clock to detect local regressions or advance an anchor during the process lifetime;
• persisted high-water or a new incarnation/reuse protocol for restart safety;
• clock-skew monitoring and a documented rollback policy.

flowchart TD
    Call([nextId]) --> Own{Ownership valid?}
    Own -->|no or uncertain| Stop[Fail closed]
    Own -->|yes| Read[Read epoch time and local state]
    Read --> Regress{observed time below last issued?}
    Regress -->|yes| Policy[Wait, fail, or advance documented logical time]
    Regress -->|no| Same{same timestamp?}
    Same -->|yes| Inc[Increment sequence]
    Same -->|no| Reset[Advance timestamp and reset sequence]
    Inc --> Full{sequence exhausted?}
    Full -->|yes| Backpressure[Wait or fail until a safe later timestamp]
    Full -->|no| Pack[Pack and update high-water state]
    Reset --> Pack
    Policy --> Pack
    Pack --> Return([Return ID])

Figure 3. Ownership validity, rollback policy, sequence budget, and high-water update are part of the algorithm.

Never silently set the timestamp backward and reset sequence. For a small rollback, a generator may retain lastIssuedTimestamp and continue incrementing sequence; if that sequence fills before wall time catches up, it must wait or fail. Another design blocks immediately. Choose the availability versus time-accuracy contract and test it.

Restart safety

Restarting a process resets its in-memory sequence. If it reuses the same worker namespace while wall time is equal to a previously used millisecond, it can repeat IDs. Prevent that with durable last-issued state, a distinct incarnation, a guaranteed wait/quarantine past the previous high-water mark, or a never-reused worker namespace.

Persisting every ID would defeat the design. Persist high-water state in batches with a reserved logical range, or make incarnation uniqueness carry restart safety. On startup, refuse to mint until the recovery invariant is proven.

Concurrency and batching

One logical worker needs one serialized state machine. Use a lock, atomic packed state, or preallocated subranges whose non-overlap is proven. Multiple library instances with the same worker ID are multiple generators, even if they run on one host.

Batch allocation can reduce synchronization and RPC cost, but unused IDs and process crashes create gaps. Gaps are normal; never promise contiguous identifiers.

Ordering semantics

Within one correctly serialized worker incarnation, the implementation can make IDs strictly increasing. Across workers, wall-clock skew can invert values across several milliseconds, and worker bits arbitrarily break equal-timestamp ties.

sequenceDiagram
    participant A as Worker A clock +20 ms
    participant B as Worker B clock -15 ms
    Note over A,B: Real event at B happens first
    B->>B: mint timestamp 1000
    A->>A: later real event, mint timestamp 1035
    Note over A,B: order appears correct here, but reversed skew can invert it
    A->>A: real event, mint timestamp 1100
    B->>B: later real event, mint timestamp 1070
    Note over A,B: integer order now disagrees with real event order

Figure 4. Approximate time order is bounded by clock behavior, not merely by events sharing one millisecond.

If strict global order is a requirement, use a coordinated sequence or ordered allocation service and accept its availability and latency boundary. Do not infer causal order from Snowflake or UUIDv7 values.

Step 6 - Operations, Regions, and Migration

Regions and environments

Reserve disjoint namespace bits or allocation ranges for production environments and regions if values can meet in one store. Region bits make uniqueness local and fast but reduce worker capacity and complicate failover: a failed region cannot casually reuse another region's namespace.

Use a versioned allocation registry, capacity alarms, and explicit emergency ranges. A new region or disaster-recovery process must obtain a nonconflicting worker/incarnation before minting. Control-plane outage may allow existing validated owners to continue only within their documented ownership window; new owners fail closed.

Epoch and layout migration

The epoch is a deadline. Alert years before exhaustion and choose one of:

• introduce a new layout/version in a wider field;
• reserve version bits from the beginning;
• move storage and APIs from 64-bit to 128-bit IDs;
• keep old IDs opaque while new writers emit the new format.

Dual-read and dual-schema migrations need collision-free namespaces, parser compatibility, sorting semantics, and rollback. Never repurpose old bits while consumers still decode them.

Failure modes and observability

Track:

• IDs minted and latency by worker/incarnation, plus concurrency contention;
• sequence utilization, exhaustion, wait duration, and rejected requests;
• wall-clock offset, rollback size, logical-time lead, and time spent waiting;
• worker allocation, renewal uncertainty, duplicate assignment attempts, and fail-closed events;
• recovered high-water state, startup quarantine, state persistence lag, and restart count;
• remaining timestamp years and worker namespace utilization by region/environment;
• database uniqueness violations and sampled decoding sanity, without claiming sampling proves zero collisions.

Use unique constraints where available as a last defense and incident signal. A duplicate must page operators and halt the affected generator; blind retry with another ID can leave earlier external side effects ambiguous.

Security and interoperability

Snowflake fields expose approximate creation time and often topology or volume. Treat IDs as identifiers, never credentials. If public enumeration matters, use an independently authorized lookup and, where appropriate, a separate CSPRNG-based public ID.

Document decimal-string JSON encoding, signed database comparison, language shifts/masks, and test vectors. Cross-language golden tests should cover epoch boundaries, maximum worker and sequence values, rollback, restart, and overflow.

Reference Architecture

The reusable pattern is:

Encode time locality and a unique generator namespace into the value, but treat worker ownership, serialized state, clock rollback, and restart high-water as correctness state outside the bit-packing function.

flowchart LR
    Control[Versioned namespace control] --> Guard[Ownership and incarnation guard]
    Clock[Epoch plus monotonic clock policy] --> State[Serialized generator state]
    Recovery[Durable high-water or safe reuse] --> State
    Guard --> State
    State --> Pack[Pack timestamp, namespace, sequence]
    Pack --> ID[(Opaque ID)]

Figure 5. Local packing is fast because the slower ownership and recovery invariants have already been established safely.

The same reasoning applies to log offsets, trace IDs, ordered event keys, and any scheme that trades coordination for structured local namespaces.

Common Interview Mistakes

• Starting with Snowflake before asking whether a database sequence or UUIDv7 is simpler.
• Treating the theoretical sequence budget as measured sustainable throughput.
• Claiming CLOCK_MONOTONIC is a shared epoch timestamp or survives reboot unchanged.
• Resetting sequence after restart without durable high-water, incarnation, or safe worker reuse.
• Assuming an expired lease stops an old process from minting IDs.
• Ignoring serialization across threads, processes, forks, or duplicate library instances.
• Calling IDs globally monotonic and limiting disorder to one millisecond despite clock skew.
• Using an ID as authorization or claiming it is automatically an idempotency key.
• Sending 64-bit integers through JavaScript Number and losing precision.
• Shipping a finite epoch and bit layout without capacity alarms or migration.

Quick Reference

Sources

• RFC 9562: Universally Unique IDentifiers - UUIDv4/v7 layouts, monotonicity, state, sorting, opacity, and security guidance.
• Twitter's archived Snowflake repository - historical service context and retirement status of the public implementation.
• Linux clock_gettime manual - CLOCK_MONOTONIC, CLOCK_BOOTTIME, epoch, NTP, and suspend semantics.
• etcd: leases and fencing - why lease ownership alone does not protect an external resource and where revision validation is required.
• etcd v3 API - lease TTL, keepalive, and revision semantics.

Frequently Asked Questions

What is a Snowflake ID?

Snowflake is a family of 64-bit, time-ordered identifier layouts rather than one universal standard. Twitter's retired implementation popularized a sign bit, 41 timestamp bits, 10 datacenter-plus-worker bits, and 12 sequence bits. Uniqueness holds only if timestamp, worker ownership, sequence serialization, and restart rules preserve a unique tuple; the bit layout alone is not enough.

Why not just use UUIDs?

Often you should. UUIDv4 avoids coordination and is opaque but has random B-tree insertion locality; standardized UUIDv7 puts a 48-bit Unix-millisecond timestamp first and keeps 74 bits for randomness or optional monotonic fields. Snowflake is compact at 64 bits and can be locally ordered, but it leaks timing, needs worker and clock operations, and has a finite epoch. Choose from width, index behavior, interoperability, opacity, and failure tolerance.

How does Snowflake stay decentralized safely?

Each active generator needs an exclusive worker namespace and serialized local state, but a lease by itself does not fence an old process. Stop minting when ownership is uncertain and use non-reused assignments, an encoded incarnation, or a persisted high-water mark plus safe reuse protocol. If a worker ID can be reassigned while an old owner still runs, hot-path arithmetic can produce silent duplicates.

What happens when the system clock goes backwards?

Read epoch time for the encoded timestamp and compare it with durable or safely recovered last-issued state. A process-relative monotonic clock can measure elapsed time or advance an anchored logical clock, but it cannot replace the shared epoch and resets at boot. On regression, wait, fail, or advance a documented logical timestamp; never reset the sequence into a timestamp-worker pair that may already have been used.

What happens when more than 4,096 IDs are requested in the same millisecond?

A 12-bit sequence has exactly 4,096 values for one worker and timestamp. On exhaustion, apply backpressure until a later safe timestamp, fail the call, or advance logical time only if the ordering contract and restart state support it. Widening sequence bits or adding workers changes other capacity limits, so benchmark sustainable throughput instead of treating 4.096 million IDs per second as guaranteed.

Are Snowflake IDs globally monotonically increasing?

No. A correctly serialized generator can be monotonic within one worker incarnation, but IDs from different workers can be inverted by clock skew and by worker-bit tie breaking, not only within the same millisecond. Global monotonic order requires a coordinated sequencer or ordered allocation service. Snowflake provides useful approximate time locality when clock-skew and rollback bounds are explicit.

Related Articles

• System Design Interview Problems: A Senior's Roadmap - the full series index and pattern library.
• System Design Interview Guide: The 6-Step Framework - the method this walkthrough applies.
• Design a URL Shortener - Part 1; database sequences and range allocation as alternative ID strategies.
• Design a Payment System - Part 11; the difference between identity and idempotency.
• Design a Job Scheduler - Part 12; leases, fencing, and durable workflow identities.
• Design a Key-Value Store - Part 14; membership epochs and decentralized state.

This is Part 13 of an extended system design series. Next: Design a Key-Value Store.