Design a Unique ID Generator

Every row you save needs an ID — a unique number that names it. The easy trick is to let one database hand out IDs that count up: 1, 2, 3, and so on (this is called auto-increment). That works great with one database. But the moment you have many databases, it breaks. One machine is not big enough for everything, and making all the machines share a single counter is slow, because every ID now waits for a network message. So the real interview question is: how do you create a unique, number-only, 64-bit, time-sortable ID on many machines without them having to talk to each other? The answer the industry agreed on is Twitter Snowflake.

Step 1: Pin down the requirements and the scale

Start by agreeing on the requirements with the interviewer. The usual back-and-forth lands on these five:

• IDs must be unique (no two are ever the same).
• IDs are numbers only (no letters or dashes).
• IDs fit in 64 bits (so they fit a normal integer column).
• IDs are ordered by time — an ID made in the evening is bigger than one made that morning.
• The generator can make more than 10,000 IDs per second.

Back-of-the-envelope estimation

This is just rough math you do in your head to check that a design is big enough — no calculator needed.

Throughput target:   > 10,000 IDs/sec  (stated requirement)

Snowflake per-machine ceiling:
  sequence = 12 bits  →  2^12 = 4096 IDs per millisecond per machine
                      →  4096 × 1000 ≈ 4,000,000 IDs/sec per machine

Headroom:  4,000,000 / 10,000 ≈ 400×  on a SINGLE machine

Timestamp lifetime:
  timestamp = 41 bits  →  2^41 − 1 = 2,199,023,255,551 ms
  2,199,023,255,551 ms / 1000 / 86400 / 365 ≈ 69 years

So one box alone already does 400 times more than we need, and a 41-bit timestamp (counted in milliseconds) lasts about 69 years before we have to reset the start date. Those two numbers are the whole sizing story.

Step 2: Look at the options (and why three of them lose)

There are four common ways to do this. Walk the interviewer through all four — naming each one's flaw is half the points — and then land on Snowflake.

Multi-master replication

Let each database count up on its own, but jump by k = the number of servers instead of by 1. With two servers, one gives out 1, 3, 5, … and the other gives 2, 4, 6, … — no clashes, and you get more throughput by adding servers. It loses because the IDs do not grow with time across servers, it is awkward across multiple datacenters, and adding or removing a server breaks the jump-counting.

UUID

A UUID is a 128-bit value (for example 09c93e62-50b4-468d-bf8a-c07e1040bfb2) that each server can make on its own with zero coordination — so it scales easily and almost never clashes (per Wikipedia, making 1 billion UUIDs every second for ~100 years gives only a 50% chance of one duplicate). It loses for this problem because it is 128 bits, not 64; it has letters, not just numbers; and it is not sorted by time.

Ticket server (Flickr)

One database whose only job is to hand out the next number — every app server asks it for one. The good parts: the IDs are numbers, and it is dead simple at small or medium scale. It loses because that one server is a single point of failure (if it dies, no one gets IDs). You could run several ticket servers, but then you are back to the syncing problem you were trying to avoid.

Step 3: High-level design — Twitter Snowflake

The 64 bits are split like this:

 0 | 41-bit timestamp (ms since epoch) | 5-bit DC | 5-bit machine | 12-bit seq
sign|<--------------------------------->|<------->|<------------->|<---------->|
 63                                                                           0

The key idea is divide and conquer: each machine can fill in every section by itself. The timestamp comes from the machine's own clock, the datacenter and machine IDs are fixed settings, and the sequence is a small local counter. Nothing here needs another machine, so making an ID is just a few bit-shifts — no lock, no database call.

Step 4: Deep-dive on the interesting sections

Timestamp (41 bits) — why IDs sort by time

The timestamp sits in the highest bits, so a bigger timestamp always makes a bigger number — and that is exactly what makes Snowflake IDs sort by time. Twitter's default start date (its "epoch") is 1288834974657 (Nov 04 2010, 01:42:54 UTC). Picking a start date near "today" pushes the 69-year limit far into the future. After 69 years you need a new start date or a migration.

Datacenter + machine IDs (5 + 5 bits) — uniqueness without talking

These 10 bits are set when the machine boots and never change. They are what make sure two different machines can never make the same ID, even if they both mint one in the same millisecond — and they do this with no coordination at runtime.

Sequence number (12 bits) — bursts inside one millisecond

The sequence is a per-machine counter. It goes up by 1 for each ID made in the same millisecond, and resets to 0 when the clock ticks to the next millisecond. With 12 bits that is up to 4096 IDs per millisecond (about 4 million per second) on one machine before it has to wait for the clock to move forward.

Tuning the section sizes

The bit widths are a budget, not a law. A slow, long-lived service can borrow bits from sequence and give them to timestamp for more years of room; a very busy service does the opposite. Mentioning this shows you see the design as adjustable, not fixed.

Step 5: Wrap up

Snowflake wins because it meets every requirement at once: IDs are 64-bit, numbers only, unique across machines with no coordination, and ordered by time. Three things worth raising if you have time left:

The arc to rehearse: 5 min requirements + sizing → 5 min options → 10 min the Snowflake layout → 10 min deep-dive on timestamp / sequence / clock-sync → wrap. The interviewer is grading your process — the option survey and the clock-sync caveat — just as much as the final answer.

Practice

Answer these to check you understood Snowflake.