Unique ID Generator System Design

Designing a unique ID generator looks trivial at first glance. There is no user interface, no complex product workflow, and no distributed cache to diagram. The system produces identifiers. That is all.

And yet, this is one of the most revealing System Design interview problems at the mid-to-senior level.

IDs sit beneath everything. They identify users, orders, invoices, messages, and log events. If ID generation breaks, the failure propagates everywhere. Duplicate IDs corrupt databases. Poor ordering hurts index performance. Clock bugs silently reorder event streams. Subtle flaws in ID design can ripple across services you have never seen.

Interviewers ask this question because it compresses deep distributed systems trade-offs into a small surface area. They are not testing whether you can name an algorithm. They are testing whether you understand:

• Correctness under concurrency

• Trade-offs between ordering and availability

• Operational risk in distributed environments

A senior engineer does not treat ID generation as a utility. They treat it as infrastructure.

The smaller the surface area of a system, the more clearly your reasoning shows.

If you handle this problem with maturity, you signal that you can reason about distributed correctness under pressure.

Framing the problem: What the ID is used for#

Before drawing boxes, you must anchor the problem in context. An ID generator for database primary keys is fundamentally different from one used for public URLs or analytics event streams.

Imagine three scenarios.

In the first, IDs are database primary keys in a write-heavy transactional system. The primary concern is uniqueness and index locality. Ordering matters because it influences B-tree performance.

In the second, IDs represent entries in an event log processed by downstream analytics. Here, rough time ordering can dramatically simplify replay and aggregation.

In the third, IDs are exposed in public URLs. Suddenly, predictability and enumeration risk become security concerns.

This is why the first five minutes of your interview matter. You clarify:

• Is global uniqueness required across regions?

• Does ordering need to reflect creation time?

• What throughput are we targeting at peak?

Only after translating answers into properties should you propose a design.

Interviewers are listening for whether you ask what the ID is used for, not just how to generate it.

What strong candidates do differently#

Strong candidates resist the urge to jump to an algorithm.

Instead of saying, “We can use Snowflake” or “Let’s use UUIDs,” they walk the interviewer through their reasoning. They convert vague business statements into precise system properties. They articulate trade-offs before selecting a mechanism.

They also narrate risk.

When they choose time-based IDs, they immediately acknowledge clock skew. When they choose random IDs, they address collision probability and indexing cost. When they choose distributed generators, they discuss node identity coordination.

Most importantly, they are explicit about what they are giving up.

Monotonicity across regions? Not feasible without coordination. Strict ordering? Expensive at global scale. Predictability? Dangerous if IDs are public.

The difference is not knowledge. It is intentionality.

Requirements walkthrough: Thinking out loud in the interview#

Let’s simulate how a strong candidate might handle the problem.

You begin with clarifying questions:

• “Are IDs required to be globally unique across all regions?”
  “Yes.”

• “Do they need to be sortable by creation time?”
  “Yes, rough ordering is helpful for analytics.”

• “Is strict monotonic increase required?”
  “No, approximate ordering is fine.”

• “What throughput should we design for?”
  “Peak of 500,000 IDs per second globally.”

Now you translate these answers into properties: global uniqueness, sortable by time, high throughput, multi-region deployment, no strict monotonic guarantee required.

At this point, you explain your reasoning aloud:

“Given the throughput and multi-region requirement, a centralized counter will likely become a bottleneck and single point of failure. Since strict monotonicity isn’t required, we can relax coordination. I would consider a time-based distributed ID that encodes timestamp, region or node identifier, and a per-node sequence counter.”

You then proactively address failure:

“We need to handle clock skew and ensure node identifiers are unique. I’d also use database uniqueness constraints as a final safety net.”

This style of reasoning signals ownership and maturity.

Uniqueness, ordering, and monotonicity explained#

These properties are frequently conflated, and interviews expose that confusion quickly.

Uniqueness guarantees no two IDs are identical. This is mandatory.

Ordering means that comparing two IDs reveals which was created first. This is useful for sorting and analytics.

Monotonicity is stricter: every new ID must be larger than all previously generated IDs.

Strict monotonicity across distributed nodes requires coordination or a single authority. That introduces latency or availability trade-offs.

The differences matter. The trade-offs matter even more.

Uniqueness is the baseline. Sortability introduces clock reliance. Monotonicity introduces coordination.

When you explain this table in an interview, emphasize that monotonicity is rarely worth the global coordination cost unless there is a strong product requirement.

Exploring the design space through trade-offs#

Instead of listing algorithms, frame your design as a set of decision paths.

If strict ordering is required globally, you likely need a centralized authority or tightly coordinated distributed counter. This ensures correctness but limits availability.

If high availability and horizontal scale are the priority, independent generators with embedded node identity reduce coordination but sacrifice strict ordering.

If locality or sharding efficiency is critical, embedding region or shard bits in the ID improves routing but couples your ID format to architecture decisions.

The trade-offs can be summarized clearly:

Notice that every row explicitly states what you gain, what you risk, and how you mitigate.

That framing demonstrates senior-level thinking.

Time-based IDs and clock realities#

Time-based identifiers are attractive because they provide natural ordering and work well with database indexes. However, distributed clocks are imperfect.

Clocks drift. Machines reboot. Virtual machines pause. NTP adjustments can move time backward.

Any design that trusts the clock without a fallback is incomplete.

If a node’s clock moves backward and you generate IDs purely from timestamps, you risk producing duplicates or out-of-order IDs.

Mitigation strategies include detecting backward drift and either blocking generation temporarily, advancing a logical clock, or incrementing sequence components until wall time catches up.

This is where interviewers apply pressure.

Dialogue 1 (clock skew pressure test)#

Interviewer: “Your IDs use timestamps. What happens when a node’s clock goes backward?”
You: “If the clock moves backward within the same time window, the timestamp component could overlap with previously issued IDs. I’d detect backward drift by comparing current time with the last emitted timestamp. If time regresses, I would either pause generation until time catches up or switch to a logical increment mechanism to preserve uniqueness.”
Interviewer: “How do you detect this in production?”
You: “I’d emit metrics for clock drift events and track the difference between system time and last-issued timestamp. Alerts would trigger if drift exceeds a threshold, and generation pauses would be logged for investigation.”

This exchange demonstrates operational awareness, not just algorithm knowledge.

Random IDs and indexing implications#

Random or probabilistic IDs eliminate coordination entirely. Each node generates values independently with extremely low collision probability.

This scales effortlessly. It also maximizes availability.

The trade-off appears in storage engines. Random values distribute inserts across the key space, leading to index fragmentation and reduced locality in B-tree structures. Reads and range scans become less efficient.

You explain this trade-off in terms of system behavior, not just theory.

The key insight: probability is not a substitute for operational reasoning. Even rare collisions become real at extreme scale.

Locality, sharding, and architectural coupling#

Embedding shard or region information inside the ID can improve routing efficiency. For example, high-order bits may indicate region. Databases can then direct writes without external lookup.

This improves performance and simplifies partitioning logic. But it locks the ID format to current architecture assumptions.

If you later increase region count or rebalance shards, historical IDs may reflect outdated topology.

When discussing this trade-off, emphasize long-term maintainability. IDs are persistent. Architectural decisions encoded into them can outlive the original design.

Failure modes and how to reason about them#

Failure thinking separates mid-level from senior engineers.

Clock skew is only one failure mode. Consider misconfigured node identifiers, sequence overflow within a time window, region isolation, or restart behavior that resets counters.

At scale, “rare” becomes “inevitable.”

If two nodes accidentally share the same node identifier, their generated IDs may collide even if timestamps differ minimally. Prevent this with coordinated node registration and configuration validation.

Sequence overflow within a millisecond can occur at extreme QPS. Either widen sequence bits or allow rollover to the next time bucket with blocking logic.

Region isolation introduces split-brain scenarios if coordination is required. Decide whether availability or global ordering wins.

Finally, use downstream database uniqueness constraints as a last line of defense. Not because you expect collisions—but because you assume imperfection.

Strong candidates treat collisions as possible states, not impossible ones.

Back-of-the-envelope estimation and capacity planning#

Now demonstrate quantitative reasoning.

Assume 500,000 IDs per second globally, with peak bursts of one million per second. If distributed across ten nodes, each node must support 100,000 IDs per second.

If using millisecond granularity, one second has 1,000 milliseconds. That means each node may need to generate up to 100 IDs per millisecond at peak.

You then reason about bit allocation.

Suppose you design a 64-bit ID. You might allocate bits for timestamp, node ID, and per-millisecond sequence counter.

For example:

• 41 bits for timestamp (sufficient for decades at millisecond precision)

• 10 bits for node ID (up to 1,024 nodes)

• 12 bits for sequence (up to 4,096 IDs per millisecond per node)

This comfortably supports required throughput.

If requirements grow to two million IDs per second across regions, sequence bits or node bits may need expansion.

Dialogue 2 (scale and throughput pressure test)#

Interviewer: “We need 2 million IDs per second across regions. What breaks first?”
You: “Sequence exhaustion within a millisecond becomes the first pressure point. If per-node allocation isn’t sufficient, we either increase sequence bits or scale horizontally by adding nodes with unique identifiers.”
Interviewer: “What if a region is partitioned from the rest?”
You: “If IDs are generated independently per region, generation continues locally. We sacrifice global ordering but preserve availability. Once connectivity restores, IDs remain globally unique because region bits prevent collision.”

This demonstrates capacity reasoning combined with availability trade-offs.

Operational readiness and observability#

ID generators are silent until they fail. That makes observability critical.

Metrics should include generation rate per node, clock drift events, sequence exhaustion frequency, latency spikes, and error counts. Rare anomalies must be visible before they escalate.

Alert thresholds should be conservative for drift and sequence overflow. Incident playbooks should define actions for node misconfiguration, clock rollback, or duplicate detection.

Designing an ID system without monitoring is irresponsible. In interviews, acknowledging observability shows real-world experience.

Invisible infrastructure requires visible signals.

Security and abuse considerations#

If IDs are public, predictability becomes a threat. Sequential or time-based IDs allow enumeration attacks, where attackers infer total user count or scrape resources.

Timestamp components may leak traffic patterns or system growth rates.

One approach is separating internal IDs from public-facing IDs. Internal IDs can optimize for locality and performance. Public IDs can be opaque mappings that hide structure.

Threat modeling at interview depth means identifying:

• Can attackers guess valid IDs?

• Can traffic volume be inferred?

• Can shard or region info be leaked?

You need not dive into cryptography. But showing awareness of enumeration risk elevates your answer.

Interview communication strategy#

You typically have 45 minutes.

Spend the first five clarifying requirements. Spend the next ten defining properties and trade-offs. Then propose a design aligned with stated priorities. Use the remaining time to address failure modes, scale, and operational concerns.

Avoid presenting an algorithm as the answer. Present reasoning as the answer.

If you sacrifice monotonicity for availability, say so explicitly and justify it. If you choose time-based encoding, explain clock mitigation before being asked.

In ID generation interviews, clarity of reasoning matters more than cleverness.

The interviewer is grading your mental model, not your memory.

Common pitfalls and how to avoid them#

Many candidates jump directly to a known solution name without mapping it to requirements. Others assume clocks are perfectly synchronized or that collision probability is “basically zero.”

Another common mistake is overengineering. If the system only needs uniqueness within a single database shard, a simple auto-increment column may suffice.

Depth does not mean complexity. It means deliberate trade-offs.

Final words#

Unique ID generation is a deceptively compact System Design problem. It tests how you reason about correctness, ordering, availability, failure, scale, security, and operations—all within a small abstraction.

If you clarify requirements, translate them into explicit properties, justify trade-offs, and proactively discuss failure and monitoring, you demonstrate the thinking pattern interviewers look for in mid-to-senior engineers.

Design the reasoning first. The encoding comes second.

Happy learning!