Mission
Interactive Simulation
Before we explain anything — play. Push it until it breaks, then fix it.
Strategy
Fleet & demand
Break it
What just happened?
A single auto-increment database was simple but became both a bottleneck and a single point of failure. UUIDs removed coordination but were 128-bit and unsortable. Snowflake packed a timestamp, datacenter, machine and sequence number into 64 bits so every machine could mint IDs locally — as long as the bit budget fit your fleet and clocks never ran backwards.
The concept
Distributed ID generation options: database auto-increment (simple, SPOF), multi-master with step k (no SPOF, but not time-ordered and hard to resize), UUID (no coordination, but 128 bits and random), a ticket server (easy, still a SPOF), and Snowflake-style IDs: 1 sign bit + 41-bit millisecond timestamp + 5-bit datacenter + 5-bit machine + 12-bit sequence. Snowflake IDs are generated locally, fit in a BIGINT, and sort roughly by creation time.
Trade-offs
Nothing is free. Here's what this solution costs you.
In the real world
Conceptually similar to Twitter Snowflake, Instagram's sharded ID scheme and Discord's message IDs.
Mini quiz
Why are random UUIDs a poor primary key for a large MySQL/Postgres B-tree?
Interview me
The app becomes your interviewer. One question, in your own words.
Boss challenge
Re-balance the bits
30 datacenters, 50 machines each, 2,000 IDs per millisecond per machine — and a clock is about to jump backwards.
Goal: Use a 64-bit, sortable, coordination-free scheme that fits the fleet, never duplicates, and lasts 30+ years.
Use the simulator above with no hints. These checks update live as you play.
Interview question
“Design a unique ID generator for a distributed system: 64-bit, time-sortable, 10K+ IDs/s per node across many datacenters. Compare UUID, ticket server and Snowflake, and explain how you handle clock skew.”