Unique IDs Across a Distributed System
mediumConcept probeVery commonly asked~25 minPhone screenHLD roundBar raiserSDE-2 and upAmazonUberFlipkartRazorpayPhonePeMicrosoftStorage & Data ModellingConsistency & ConsensusCapacity & Estimation
The question, as asked
“We need unique IDs for every order in the system. Auto-increment doesn't work any more now that the database is sharded. What do you do?”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Does the ID need to be sortable by creation time? This is the question that decides between UUIDv4 and everything else, so ask it first.
- Is it user-visible? If people will read it out on a support call, length and the absence of look-alike characters matter. If it's in a URL, guessability matters.
- Must it be unguessable? Sequential order IDs leak your order volume and let someone enumerate other people's orders.
- How many IDs per second, and across how many nodes? The answer decides how many bits you need and whether coordination is viable at all.
- Strictly monotonic, or roughly time-ordered? Strict global monotonicity requires coordination; 'sorts correctly to the second' usually doesn't — and the gap between those two is most of the design.
- What's the storage and index cost sensitivity? A 128-bit random ID as a primary key behaves very differently from a 64-bit time-ordered one, and at large scale that difference is measurable.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.