The Problem That Fits in 64 Bits: Designing a Unique ID Generator

maang.io System Design Series

"Design a unique ID generator" sounds like the shortest interview of your life. Candidates reach for one of two reflexes: "just use a UUID" or "just use Snowflake." Both can be the right answer, but neither one comes with a reason. Interviewers keep asking because the follow-ups expose that immediately. Why not a UUID, when it needs no coordination at all? Where did your 41 timestamp bits come from, and when do they run out? What does your generator do when the clock moves backwards? What stops two machines from claiming the same worker ID?

This module answers each of those questions with arithmetic and mechanisms rather than brand names.

The Trap Built Into a One-Line Problem

A deceptively small prompt fails candidates in two predictable ways:

• The Recital: the candidate names a scheme ("Twitter Snowflake: timestamp, machine, sequence") without sizing a single field. When the interviewer changes one constraint, there's no reasoning underneath to adapt.
• The Citadel: the candidate, afraid of looking junior, runs every ID through a consensus protocol or a global sequencer, putting a cross-region round trip on the write path of every record in the company.

The passing answer sees that "unique" is easy; "unique, 64 bits, roughly time-ordered, and never coordinated per ID" is the problem. Allow 128 bits and a UUIDv7 minted in-process wins with no service at all. Take the bits away and you have to spend them carefully. Once you do, your correctness quietly rests on two things that fail in production: clocks and worker IDs.