Unique ID Generation (Snowflake-style)
Distribution & PartitioningGenerates globally unique, roughly time-sortable IDs across many machines without a shared auto-increment counter.
Once a system is sharded, you can no longer rely on a single database's auto-increment column to hand out unique primary keys — two shards would eventually generate the same ID. Twitter's 'Snowflake' approach (widely copied — Discord, Instagram, Sony all have variants) solves this by encoding a 64-bit ID from three parts generated independently on each machine: a timestamp (so IDs are roughly sortable by creation time), a machine/worker ID (so different machines never collide), and a per-machine sequence number (so the same machine can generate many IDs within the same millisecond). No coordination between machines is required at generation time.
How it connects
Unique ID Generation (Snowflake-style) as the source, with the components it typically interacts with.
- → Database Types (SQL, NoSQL & Beyond): Generated IDs (Snowflake-style or DB sequences) are used as primary keys/shard keys, and their structure often encodes shard/timestamp info the database routing depends on.
- → Consistent Hashing: Where IDs aren't naturally uniform, consistent hashing is applied on top of the generated ID to distribute rows evenly across shards.