SoupCalc

Snowflake ID Generator: Inside Twitter's 63-Bit Distributed Identifier

What Is a Snowflake ID?

A Snowflake ID is a 63-bit integer used to generate unique identifiers across a distributed system without a central coordination point. Twitter developed the format in 2010 to replace auto-incrementing database sequences that could not scale across dozens of application servers writing to sharded MySQL clusters. Each Snowflake ID is a signed 64-bit integer where the most significant bit is always zero, leaving 63 payload bits partitioned into four fields: a 41-bit timestamp offset, a 5-bit datacenter identifier, a 5-bit machine identifier, and a 12-bit sequence number. This layout lets a single Snowflake service node generate up to 4,096 unique IDs per millisecond, giving the system a theoretical throughput of millions of IDs per second across a deployment of hundreds of worker processes.

Snowflake IDs are monotonically increasing — each new ID is larger than the last within the same epoch — but they are not strictly sequential between nodes. Two machines operating in the same millisecond will produce IDs that interleave, which is a deliberate trade-off: the scheme sacrifices perfect ordering for absolute operational independence. Each worker need only know its own datacenter and machine number, plus the current time, to produce a globally unique identifier without ever consulting a peer or a lock service.

Anatomy of the 63-Bit Identifier

The Snowflake ID is a 63-bit integer composed of the following fields, from most significant to least significant:

  • 41-bit timestamp — milliseconds elapsed since a custom epoch.
  • 5-bit datacenter ID — identifies the physical datacenter hosting the worker.
  • 5-bit machine ID — identifies the individual host or process within that datacenter.
  • 12-bit sequence number — a per-millisecond counter that resets to zero when the clock ticks forward.

The exact phrase that describes this layout is: a 41-bit timestamp, 5-bit datacenter, 5-bit machine, and 12-bit sequence. Together these fields occupy 63 bits, with the leading sign bit set to zero so the ID fits comfortably in a signed 64-bit integer in languages like Java and C#.

The Twitter Epoch and Timestamp Component

Every Snowflake ID carries a timestamp offset measured from a custom epoch: 1288834974657 milliseconds. This value corresponds to approximately 2010-11-04T04:42:54.657Z and was chosen to align with the start of Twitter's internal Snowflake deployment. Using a custom epoch rather than the Unix epoch means the 41-bit timestamp field can represent a range of roughly 69 years before overflowing. The maximum timestamp value the field can hold is 2^41 minus 1, or 2,199,023,255,551 milliseconds — about 69.7 years after the epoch, which pushes the rollover date into the 2080s.

To encode a timestamp, subtract the epoch from the current Unix-epoch milliseconds, then left-shift the result by 22 bits to make room for the three lower fields. Any input timestamp earlier than the epoch is invalid and must be rejected.

Datacenter and Machine Node Identification

The 5-bit datacenter field and the 5-bit machine field each accept values from 0 through 31, yielding a total of 1,024 unique node identifiers across a deployment. A worker is assigned a datacenter ID and a machine ID at startup, typically through a configuration file, a coordination service like ZooKeeper, or a command-line argument. The assignment must be unique within the fleet: two workers sharing the same (datacenter, machine) pair will produce colliding IDs unless their clocks are out of phase.

These fields are inserted into the ID by left-shifting the datacenter value by 17 bits and the machine value by 12 bits, then OR-ing the shifted values into the 63-bit integer. The total node count of 1,024 is sufficient for most real-world deployments, but environments that need more than 1,024 workers can steal bits from the sequence field or the timestamp field at the cost of throughput or epoch range.

The Sequence Counter and Clock Boundaries

The 12-bit sequence field is the workhorse of the Snowflake design. It runs from 0 through 4,095 and increments by one for each ID generated within the same millisecond. When the sequence reaches 4,095, the worker spins in a busy loop until the system clock advances to the next millisecond, at which point the sequence resets to zero and generation resumes. This gives a single node a maximum burst rate of 4,096 IDs per millisecond.

Clock drift and clock rollback are the two most significant failure modes of the Snowflake algorithm. If the system clock moves backward — whether due to an NTP correction, a virtual machine migration, or a manual change — a worker could generate an ID with a timestamp that is smaller than the last one it produced, breaking the uniqueness guarantee. The standard mitigation is to halt ID generation and raise an error when clock rollback is detected, refusing to serve requests until the clock catches up to the last-seen timestamp. A deployment that cannot tolerate downtime should consider a dedicated time service or a logical clock layer.

Worked Example

Consider the following input values: a Unix-epoch timestamp of 1700000000000 milliseconds, a datacenter ID of 7, a machine ID of 13, and a sequence number of 4095.

Encoding. First compute the timestamp offset: 1700000000000 minus the Snowflake epoch 1288834974657 equals 411165025343. Left-shift this offset by 22 bits to obtain 1724551110456246272. Left-shift the datacenter value 7 by 17 bits to get 917504. Left-shift the machine value 13 by 12 bits to get 53248. The sequence number requires no shift. Combine the four terms with bitwise OR to produce the final Snowflake ID: 1724551110457221119.

Decoding. To recover the original fields from the ID 1724551110457221119, mask the lowest 12 bits to extract the sequence: 4095. Shift right by 12 bits and mask the lowest 5 bits to recover the machine ID: 13. Shift right by 17 bits and mask the lowest 5 bits to recover the datacenter ID: 7. Shift right by 22 bits to obtain the timestamp offset: 411165025343. Add the epoch 1288834974657 to recover the original Unix-epoch timestamp: 1700000000000.

The round-trip is exact because every field fits within its allocated bit width and no information is lost during encoding.

Accuracy and Limitations

The Snowflake encoding scheme is deterministic and reversible provided all inputs fall within their valid ranges. The timestamp offset must be a non-negative 41-bit integer; the datacenter and machine IDs must be in the range 0 through 31; and the sequence must be in the range 0 through 4,095. Any input outside these bounds is rejected as invalid.

The scheme does not account for leap seconds or sub-millisecond precision. It relies on the host system clock, which can drift or be adjusted by external processes. In deployments where the system clock is forwarded by a large NTP jump, the offset field will advance correctly, but the sequence counter will have been idle during the gap, leaving a period of unissued IDs. This is harmless for uniqueness but creates a discontinuity in the ID timeline.

Network-partitioned workers that share the same (datacenter, machine) tuple will produce colliding IDs if they are ever active concurrently. The identifier space provides 1,024 unique node slots, and exceeding that count requires a custom bit-layout variant.

Sources

Editorial Record

This article describes the Snowflake ID format as defined in Twitter's 2010 reference implementation. The bit layout and epoch value are drawn directly from the open-source Scala source code. The worked example was verified with a manual computation that encodes and decodes the same values to confirm the round-trip. The discussion of clock rollback and node limits reflects operational experience documented in the engineering literature on distributed ID generation.

The article does not cover third-party implementations or variants that alter the bit layout — such as those that use a 10-bit machine ID, a different epoch, or a worker-ID field drawn from a coordination service. Those variants are outside the scope of the original Snowflake specification. Author: SoupCalc Editorial Team Last reviewed: August 11, 2026.