Generate Snowflake IDs for distributed systems
Snowflake IDs (Twitter) combine timestamp, machine ID, and sequence number for unique, sortable IDs in distributed systems without coordination.
- 1
Snowflake is a 64-bit ID: 41 bits timestamp (milliseconds since epoch, ~69 years), 10 bits machine ID (1024 machines), 12 bits sequence (4096 IDs per millisecond per machine). This generates ~4 million IDs per second, sorted by time, with no coordination between machines. Used by Twitter, Discord, Instagram. The machine ID must be unique per generator — assign via ZooKeeper, Etcd, or a machine ID service.
- 2 Timestamp Converter →
Get the current millisecond timestamp for the Snowflake time component. The timestamp should be milliseconds since a custom epoch (not Unix epoch) to maximize the 41-bit range. For example, epoch 2020-01-01 gives ~69 years of IDs. The timestamp provides time-ordering and uniqueness across time.
- 3 Precision Calculator →
Combine the components: id = (timestamp << 22) | (machineId << 12) | sequence. The bit shifts position each component. Verify the bit widths: timestamp (41 bits) + machineId (10 bits) + sequence (12 bits) = 64 bits. The sequence increments within a millisecond and resets when the timestamp advances.
- 4 UUID / ULID Generator →
Generate a UUID for comparison. Snowflake is 64 bits (8 bytes, fits in a BIGINT); UUID is 128 bits (16 bytes). Snowflake is sortable by time; UUID is not. Snowflake requires machine ID coordination; UUID does not. Use Snowflake for high-throughput distributed systems; use UUID for simpler systems or when no coordination is available.
Frequently asked questions
- How do I assign unique machine IDs?
- Options: (1) ZooKeeper/Etcd — atomically claim an ID, release on shutdown. (2) Config file — manually assign IDs to each server. (3) IP address hash — hash the machine's IP to a 10-bit ID (collision risk). (4) Cloud metadata — use instance ID from AWS/GCP. (5) Database sequence — atomically increment. The machine ID must be unique — duplicates cause ID collisions.
- What happens when the timestamp overflows?
- After ~69 years from the custom epoch, the 41-bit timestamp overflows. This causes IDs to wrap around, breaking sortability and potentially causing collisions. Plan the epoch to be close to your deployment date. If you approach the limit, migrate to a new epoch (requires updating all ID generation, but existing IDs are not affected).
Workflows that solve this
Learn more
Want to understand why?