Snowflake IDs: an interactive unique ID generator

A Snowflake ID is a 64-bit unique ID that any machine can generate on its own, with no database round trip and no coordination: a timestamp in milliseconds, then the machine’s number, then a counter for IDs made in the same millisecond. The IDs fit in a BIGINT, sort roughly by creation time, and each machine can make 4,096 of them every millisecond. Twitter introduced the scheme in 2010; Discord, Instagram and many others use variants of it.

The playground has three machines generating IDs for ten milliseconds. Click any ID to see its bits, then try a burst bigger than the sequence allows and a clock that jumps backwards.

How a Snowflake ID is built

Choosing a recent epoch rather than 1970 matters: 41 bits of milliseconds from 1970 would run out in 2039. The split can be tuned. Instagram’s version, generated inside PostgreSQL, uses 41 bits of time, 13 bits of logical shard and 10 bits of sequence.

Unique without coordination

Two machines can never produce the same ID, because their machine bits differ, and one machine never repeats itself, because within a millisecond the sequence increases and across milliseconds the timestamp does. The only thing that needs coordinating is handing out machine numbers once, at startup: from configuration, or from a lease in ZooKeeper or etcd so a number is never used by two live processes at once.

The trouble with clocks

The scheme trusts each machine’s clock, and clocks misbehave. If a clock is stepped backwards, a generator that trusts it reuses timestamps and, starting the sequence again, repeats IDs it has already given out: 9 duplicates in the last preset. A generator must remember the last timestamp it used and wait, or refuse, until the clock passes it. Clocks on different machines also drift apart, so IDs are ordered exactly within one machine but only roughly across machines: with one clock 2 ms fast, its IDs sort as if they were made 2 ms later. That is enough for “newest first” feeds, and not enough to decide which of two events on different machines happened first.

Snowflake IDs vs UUIDs vs auto-increment

UUIDv7, standardised in RFC 9562 in 2024, puts a 48-bit millisecond timestamp in front of random bits, so it sorts by time like a Snowflake ID without needing machine numbers, at twice the size. Random UUIDv4 keys scatter inserts across a B-tree index, which hurts write performance and caching on large tables.

A Snowflake generator in code

import threading, time

EPOCH_MS = 1_704_067_200_000            # 1 January 2024

class Snowflake:
    def __init__(self, machine_id: int):
        assert 0 <= machine_id < 1024    # 10 bits, assigned so no two machines share one
        self.machine, self.last, self.seq = machine_id, -1, 0
        self.lock = threading.Lock()

    def next_id(self) -> int:
        with self.lock:
            now = int(time.time() * 1000)
            if now < self.last:          # the clock went backwards: wait rather than repeat
                time.sleep((self.last - now) / 1000)
                now = self.last
            if now == self.last:
                self.seq = (self.seq + 1) & 4095
                if self.seq == 0:        # 4,096 used this millisecond: wait for the next
                    while now <= self.last:
                        now = int(time.time() * 1000)
            else:
                self.seq = 0
            self.last = now
            return ((now - EPOCH_MS) << 22) | (self.machine << 12) | self.seq

In a system design interview

When a design needs IDs for posts, messages or orders across many servers, say how they are made: “Each service instance generates 64-bit Snowflake IDs locally, with a machine number leased from etcd at startup. They fit a BIGINT column, need no database round trip, and sort by time, so ‘newest first’ is an index scan on the primary key.” Expect the follow-ups: what happens when a clock goes backwards, how machine numbers are reused safely, and whether exposing creation time in the ID matters.

Read the guide to unique IDs and time, see composite indexes for why time-ordered keys index well, or watch a strong candidate design a unique ID generator.

Questions people ask