STANDARDwalkthrough
The 64-Bit Budget
Every service in the platform needs IDs: for tweets, orders, messages: and they must be unique across 1,000+ machines minting millions per second, with no coordination on the hot path. Twitter's Snowflake answered with a single idea: treat a 64-bit integer as a budget and spend its bits on exactly the guarantees you need.
Each field buys something. The timestamp buys k-sortability: IDs sort by creation time, so database indexes append instead of fragmenting and cursors paginate for free.
“The canonical split: 1 sign bit (kept zero so IDs stay positive in every language and database), 41 bits of milliseconds since a custom epoch, 10 bits of worker ID, and 12 bits of sequence.”
The worker ID buys coordination-free uniqueness across machines: workers can mint simultaneously without ever talking to each other. The sequence buys burst capacity within one millisecond: IDs per worker per ms, which is 4.096M IDs/sec per worker at the bit level.
Multiply out the ceiling: 1,024 workers x 4,096 IDs/ms = 4.2 billion IDs per second cluster-wide, far beyond any real load: the budget is deliberately loose. And the 41-bit clock runs ms = 69.7 years from the epoch you choose.
The deep interview move is recognizing the split is tunable, not sacred: Sonyflake spends 39 bits on 10ms ticks (174 years, fewer IDs/ms) and 16 bits on machines (65K workers) because Sony wanted more machines and less burst; Instagram spends 13 bits on shard ID inside PostgreSQL (topic 8) because their generator lives in the database. Ask what the workload needs: more workers, more burst, longer life: and move bits accordingly.
What if the interviewer asks: why 64 bits at all, not 128? Because 64 fits native integer types everywhere (BIGINT, int64, JavaScript-safe with care), halves index size versus UUIDs, and the budget above shows 64 is already generous.
Related concepts