How to Explain a Unique ID Generator in English

The prompt

Design a service that mints unique IDs for many machines. In 60–90 seconds, in English, say what unique means, how you avoid a single database, and what happens if a clock jumps.

How to explain it

1. 1. Requirements

   Who the user is, and what must work on day one.

   Clarify identity, write vs read, and one thing you are not building yet.

2. 2. Scale

   One rough number you can say out loud.

   QPS, storage, or “millions of keys.” The number can be rough. The sentence cannot be missing.

3. 3. API

   Name the two or three calls.

   “I would expose allow(userId) and a 429 when they are over the limit.”

4. 4. Data

   Where the state lives.

   Cache, database, or log. Say why that store, not a tool dump.

5. 5. Bottleneck

   What breaks first when traffic grows.

   Hot key, single leader, clock skew. Invite a follow-up.

6. 6. Trade-off

   What you gain and what you give up.

   Accuracy vs speed, consistency vs availability. One pair is enough.

• “I need IDs that are unique and roughly time-ordered.”
• “I would use a timestamp, a machine id, and a sequence.”
• “The follow-up is clock skew.”

Practise out loud

Model spoken script

I need IDs that are unique across machines and roughly time-ordered, without a single database on the write path. I would use a Snowflake-style ID: timestamp, machine id, and a sequence. That lets each node mint IDs locally. The bottleneck is clock skew — if a node’s clock jumps backwards you can collide. I would refuse to mint until the clock catches up, or keep the last timestamp. The trade-off is a UUID, which is unique and simple, but not sortable and larger on disk.