Snowflake ID bit-layout infographic: a 64-bit bar split into a 41-bit millisecond timestamp, a 10-bit machine id and a 12-bit sequence counter; two machines minting ids without talking; the backward-clock warning.

Distributed Systems

How Two Machines Agree On A Number Without Talking

Snowflake ID — a distributed ID generator that partitions bits instead of negotiating.

Core Concept

An auto-increment column is secretly a coordinator: every insert must ask one place for the next number. Snowflake deletes the coordinator by partitioning a 64-bit integer into private fields — 41 bits of millisecond timestamp in the most significant position, 10 bits of machine id, 12 bits of per-millisecond sequence. Each machine mints ids entirely on its own, and two machines cannot collide, because their ids occupy disjoint bit ranges. Uniqueness comes from the layout of the bits, not from agreement.

1
sign (0)

41 bits
millisecond timestamp

10 bits
machine id

12 bits
sequence

Time in the top bits ⇒ sorting the integers ≈ sorting by time (“k-ordered”).

Key Components

41-bit timestamp

Time in the MSB

Millisecond since an epoch, occupying the most significant bits. Gives you roughly time-sortable keys and ~69 years of range.

10-bit machine id

1,024 machines

Each generator owns a fixed field, so fleets cap at 2¹⁰ = 1,024 id mints. Disjoint fields ⇒ no collision without a message.

12-bit sequence

4,096 per millisecond

Resets each new millisecond. Exhausted within one ms ⇒ wait for the next tick. Ceiling ≈ 4.1M ids/sec per machine.

Refuse-on-rewind

The falsification

If NTP steps the clock backwards, the generator must refuse to generate — a repeated millisecond would re-issue an id that already exists.

How It Works

Read the local clock; take the current millisecond.
Pack it into the top 41 bits of a fresh 64-bit value — time first, so integer order tracks time order.
Insert this machine's fixed 10-bit id. No lookup, no network call.
Insert the per-millisecond sequence (0, 1, 2…). Reset on each new millisecond; if all 4,096 slots are used, wait one tick.
If this millisecond is earlier than the last one you issued — the clock stepped backwards — refuse to generate rather than emit a duplicate.

Why Not the Alternatives

Auto-incrementOne coordinator: a throughput ceiling and a single point of failure. Every insert asks one place for the next number.

Random UUIDv4Deletes the coordinator but throws away order, and a random 128-bit key scatters B-tree inserts across the whole index instead of appending at the hot right edge.

SnowflakeBoth properties at once: roughly time-sortable and coordinator-free. The price is one assumption — the clock only moves forward.

The Ceiling You Can Compute

The id space is a rate limit with a ceiling you can compute before you deploy rather than discover in production: 4,096 ids / machine / ms × 1,000 ms = ~4.1M ids/s per machine
2¹⁰ = 1,024 machines per fleet
⇒ budget your id throughput on paper, first

Real-World Applications

Twitter's original 64-bit ids High-throughput order & event ids Primary keys that append at the B-tree hot edge Sharded fleets minting their own keys Any globally-unique, time-ordered key with zero coordination

Checkpoint — answer before you move on

The timestamp sits in the most significant bits. What do you get for free, and what does it cost? Think about what “sorting the integers” means — and which part of the scheme now depends on it.
NTP steps the cluster clock backwards by three seconds. What must the generator do, and why is “just keep issuing” dangerous? A repeated millisecond re-enters a range you have already used…
Compute the ceiling: with 12 sequence bits and 10 machine bits, how many ids can one machine mint per second, and how many machines can a fleet hold? 2¹² per millisecond. 2¹⁰ machines.