Snowflake ID Generator

Snowflake ID: 64 bits of distributed identity

Snowflake was created by Twitter in 2010 to replace auto-increment primary keys after the company sharded its MySQL fleet. The whole point: produce time-ordered, globally unique 64-bit IDs without talking to a central server. Sixty-four bits fits cleanly into a SQL BIGINT — half the size of a 128-bit UUID — and remains numeric, which matters for languages without native 128-bit integers.

Bit layout (Twitter original)

 1 bit  | 41 bits        | 5 bits     | 5 bits  | 12 bits
 sign   | timestamp ms   | datacenter | machine | sequence
 (0)    | since epoch    | id (0-31)  | id      | (0-4095)

The Twitter epoch starts at 1288834974657 (November 4, 2010). Forty-one bits of milliseconds give the format a lifespan of 2⁴¹ ms ≈ 69.7 years before exhausting the timestamp field. The 12-bit sequence increments inside the same millisecond, so a single machine can mint 4,096 IDs per millisecond. Multiplied by 32 machines × 32 datacenters, the original design caps out at roughly 4.19 million IDs per millisecond globally.

Forks and variants

• Discord — same shape, custom epoch (1420070400000, Jan 1 2015). To read the timestamp: (snowflake >> 22) + 1420070400000.
• Instagram — replaces machine ID with a logical schema_id so the ID can be routed back to its Postgres shard.
• MongoDB ObjectId — similar idea (timestamp + machine + counter) but 12 bytes, not 8, so not technically a Snowflake.
• Sonyflake, TinyID, Seata — community ports tweaking the bit allocation for higher throughput or longer lifespan.

Trade-offs to know

Pros: 64-bit (half the storage of UUID), naturally time-sortable, no central coordinator, very high throughput. Cons: depends on a synchronised clock — NTP is mandatory — and every node needs a unique machine/worker ID assigned out of band (via config, Zookeeper, etcd, or a startup registration call).

FAQ

How do machines generate IDs without a central server? Each node owns a unique worker ID. The remaining fields (timestamp + sequence) are local, so two nodes with different worker IDs cannot collide.

What if two nodes share the same worker ID? Collisions are guaranteed inside the same millisecond. Worker ID assignment is the single hardest operational problem with Snowflake — most production setups use a coordination service (Zookeeper, etcd) or a static config file.

Is Snowflake safe to expose in public URLs? It leaks the creation timestamp and the shard layout. Avoid it in URLs that should not reveal user count, signup time, or backend topology — use a random ID for those.