Ever wondered how Discord and Twitter generate unique IDs at scale? They use a system called Snowflake. Instead of relying on a central database to generate sequential IDs, Snowflakes are distributed IDs that contain useful metadata embedded within them.
The beauty of Snowflakes is that you can extract information like the creation timestamp directly from the ID itself, without hitting the database. This makes them incredibly efficient for distributed systems handling millions of requests per second.
The Snowflake Structure
A Snowflake ID is a 64-bit integer broken down into four parts:
A Snowflake ID contains:
- • Unused – 1 bit, reserved for future use
- • Creation Date – 41 bits, milliseconds since Jan 6, 2023
- • Node ID – 5 bits, identifies which server generated the ID
- • Worker ID – 5 bits, identifies which worker thread on that server
The unused bit is reserved for future use. The creation date stores milliseconds since a custom epoch, allowing you to extract the timestamp from any ID. Node ID represents which server generated the ID, and Worker ID represents which worker thread on that server created it.
Why This Matters
Snowflakes eliminate the need for a central ID service while embedding temporal and operational metadata directly into the ID.
Instead of storing a separate 'created_at' column in your database, you can extract it from the ID itself. Need to know which server generated a user's ID? Check the node ID. This reduces database queries, improves performance, and scales beautifully.
With up to 31 nodes and 31 workers per node, you can support 961 concurrent workers. Each worker can generate thousands of IDs per millisecond, giving you the throughput needed for any scale.
If you're building a system that needs to generate millions of IDs without a bottleneck, Snowflakes are the way to go. Check out the SnowFlake-Generator on GitHub to implement it in your own projects.
View the SnowFlake-Generator Project