Unique ID Generator System Design Interview: Talk It Through

The unique id generator system design interview is a reasoning test, not a memory test. In the first five minutes, pin down scale, ordering and coordination, then pick an approach and defend its cost. A common pattern in how these interviews are run is that four things get scored: how you narrow requirements, your choice of approach, your trade-off reasoning, and how you handle follow-ups. For mid-level and senior roles, the last two usually carry the most weight: defending a trade-off under pushback rather than reciting a scheme. Memorising Snowflake helps only after you have shown the requirements that make it the right answer.

What is the interviewer actually testing when they ask for a unique ID generator?

They are testing whether you can turn a vague prompt into a bounded problem. The "right" design depends entirely on requirements you extract first, which is why this question traps people who start drawing boxes. A candidate who says "Snowflake" in minute one has skipped the part being scored.

Say this in your first minute:

"Before I pick an approach, I want to pin down scale, ordering and coordination. Let me ask a few questions, then I'll compare two or three options and commit to one."

That sentence buys you time and tells the interviewer you know the shape of the problem. The four scoring areas map to the rest of the interview: requirements narrowing in the first five minutes, approach choice next, trade-off reasoning when they push back, and composure when a follow-up lands.

The first five minutes: which requirements do you need before choosing anything?

Ask these questions in roughly this order. You will not get answers to all of them; state an assumption when you do not.

• Peak rate: how many IDs per second at peak, not average?
• Ordering: must IDs sort by creation time, or only be unique?
• Guessability: can the ID appear in a URL or leak to a user? If so, it must be hard to guess.
• Scope: one datacenter or many regions?
• Clock behaviour: what happens if two machines disagree on the time?
• Lifetime: how long must uniqueness hold — forever, or for a retention window?

Two answers lead to different designs. "Sortable, 10k per second, single region" points to a timestamp-plus-machine-id scheme with a small sequence. "Unguessable, 1M per second, global" points to random UUIDs or a coordinated range allocator, because sortable IDs leak creation order and volume. Clarifying pays off because it narrows the sketch you have to defend.

When the interviewer says "you decide", state assumptions out loud:

"I'll assume 50k IDs per second at peak, sortable order matters because these are database keys, and IDs are not user-facing, so guessability is not a requirement. I'll flag if that changes the design."

Which approaches should you be able to sketch, and what does each one cost?

Have four options ready. For each, know how it works, where it breaks, and the one trade-off you say out loud.

A rule of thumb for choosing: coordination cost versus ordering versus guessability. Pick the two that matter and name the one you are giving up. This is also useful when you discuss data partitioning, because the ID often becomes the partition key.

Worked walkthrough: the unique id generator system design interview at 50k IDs per second

Here is a full narrated example. The numbers are illustrative, not measured. Said end to end, it sounds like this:

"I'll assume 50k IDs per second at peak, sortable because these are primary keys, not user-facing, single region, unique forever. I'll use timestamp plus machine id: no per-ID coordination and sortable keys. In 64 bits: 41 for a millisecond timestamp from a custom epoch, 10 for the machine id, 12 for a per-millisecond sequence. The timestamp gives decades of range, the machine id gives room for many nodes, and the sequence covers bursts within a millisecond, so 50k per second spread across a handful of nodes fits easily. If a node exhausts its sequence, I spin to the next millisecond to keep order. If the clock jumps backwards, I stop issuing until it catches up."

Requirements. The script above fixes the constraints; the work here is saying which ones drive the design. Ordering is the requirement that rules out random UUIDs, and the single region is what lets me keep the machine id small.

Approach. Timestamp plus machine id follows from those constraints. The cost I am accepting is explicit handling of clock skew and sequence overflow, and I say how before I am asked.

Bit layout. The 41-bit timestamp is the field that sets the lifetime: at a millisecond tick, each extra bit doubles the span, so 41 bits reaches well past a human career and 40 would halve it. The machine id field sets how many nodes you can run, and the sequence field sets how many IDs one node can issue within a single millisecond. If the interviewer raised the node count, I would shrink the sequence first, because per-node bursts are easier to absorb by spreading load than by adding machines.

Sequence overflow. The choice inside the quote is the one to unpack: spinning to the next millisecond trades a little latency for order, while borrowing the next millisecond's timestamp trades order for throughput. I pick spinning because ordering is the stated requirement, and I say that reason out loud rather than leaving it implied.

Clock skew follow-up. "If the clock jumps backwards, I detect it because the current timestamp is less than the last one issued. I refuse to issue until the clock catches up, or I raise an alert and take the node out of rotation. I tell the interviewer the failure mode rather than hiding it."

When you name that failure mode, add the one sentence that shows you have thought it through: "The cost is a short outage on that node, which I prefer to a duplicate key."

How do you defend the trade-offs when the interviewer pushes back?

Use a three-beat pattern: restate the constraint, name the cost you accept, name what would change your mind. It keeps the answer short and shows you are reasoning, not defending ego.

Pushback one: "Why not just use a UUID?"

"Because I said sortable keys matter. A random UUID gives me no coordination cost, but it does not sort by time, and my index would be larger. If you told me ordering did not matter and IDs were user-facing, I would switch to UUIDs, because then unguessability matters more than order."

Pushback two: "What if the ID service goes down?"

"Each node generates locally, so there is no central service to go down. The coordination is only in assigning machine ids. If a node loses its machine id, it stops issuing rather than risk duplicates. That is the cost I accept: a node that cannot confirm its id is unavailable rather than wrong."

Weak, then stronger. A weak answer lists options: "You could use a database, or UUIDs, or Snowflake, or a range allocator. They all have pros and cons." A stronger answer commits:

"Given sortable keys and 50k per second, I'll use timestamp plus machine id. I accept the clock-skew handling cost because it is the only option that gives me ordering without per-ID coordination. If you raised the rate to 1M per second across regions and still needed ordering, I would revisit a range allocator."

The difference is that the second answer defends a choice and names the condition that would change it. For more on handling the follow-up layer, see respond to follow-up questions in an interview.

What are the most common mistakes in this interview?

Three mistakes come up often. Each has a sentence that fixes it in the moment.

• Jumping to Snowflake before requirements. Fix: "Before I commit to an approach, let me confirm scale and ordering."
• Ignoring clock skew. Fix: "The failure mode I have to handle is a backward clock jump; here is what I detect and do."
• Never stating a failure mode. Fix: "The part of this design most likely to fail is the sequence overflow, and here is my plan."

A note on drawing while talking: keep the diagram minimal. Add a box only when you name it out loud, and narrate what it connects to. A diagram that grows ahead of your explanation reads as memorised; one that grows with your sentences reads as reasoning.

How should you practise this out loud before the interview?

Run a 35-minute routine, timed, out loud. It mirrors the shape of a unique id generator system design interview.

• 5 minutes: requirements checklist, including the questions you would ask.
• 10 minutes: compare the four approaches and commit to one.
• 15 minutes: deep dive on the chosen approach, including bit layout and overflow.
• 5 minutes: failure modes and clock skew.

Then self-review against three questions: did you state assumptions, name a trade-off, and handle one follow-up without repeating yourself? Record yourself and listen for filler and unstated assumptions. If you want related practice frameworks, the blog has walkthroughs for other system design prompts, including consistency models.

Before you walk in

The unique id generator system design interview rewards the candidate who narrows before designing. One takeaway: requirements first, approach second, trade-off third. One thing to do next: run the 35-minute routine once, out loud, and listen to the recording for the moment you started drawing before you finished asking.

Frequently asked questions

Do I need to know Snowflake specifically, or can I design my own scheme?

You can design your own, and a clear custom scheme usually scores better than a recited one. What matters is that you justify each field and name the failure modes. If you do name Snowflake, treat it as one known option among several rather than the answer itself.

How many IDs per second should I assume if the interviewer gives no numbers?

Anchor the figure in something you can defend rather than picking a round number at random. If you know the product's write volume, round that up and add headroom for peak; if you do not, say you are choosing a figure that is generous for a single region and invite correction. Then move on, because the interviewer is watching how you reason from the number, not the number itself.

What if the interviewer asks me to code part of the generator?

Ask whether they want a sketch or working code, then match the scope to the time left. In a shared editor, write the struct or class with its three fields first, then the next-ID method, and leave the overflow branch as a named stub if time is short. Say what you would fill in, so the gap reads as a choice rather than an oversight.

Should I mention database auto-increment at all, or is it considered wrong?

Mention it as a baseline, then say why it does not fit your requirements. It is not wrong; it is a coordination choice with a throughput cost. Naming it briefly shows you considered the simple option before the complex one.

How do I answer if I have never built an ID service in production?

Be direct about the gap in one sentence, then move to what you can reason about: the constraints, the field widths and the failure modes. You can add that you have used generated keys as a consumer of such a service, if that is true, and describe what you noticed about ordering or collisions from that side.

How long should the unique id generator system design interview answer be?

Keep your first pass short enough that you still have room for follow-ups, which is where most of the signal comes from. If time runs out mid-design, stop adding boxes and say which part you would finish next and why, so the interviewer sees a plan rather than an unfinished sketch.

Practise the walkthrough out loud before the real interview.