Snowflake ID

A Snowflake ID packs three fields into a fixed-width integer, typically 64 bits: a timestamp (milliseconds since a custom epoch), a node/worker/shard ID, and a sequence counter that increments for IDs generated within the same millisecond on the same node. The canonical Twitter layout reserves 1 sign bit, 41 bits for timestamp, 10 bits for machine ID (5 datacenter + 5 worker), and 12 bits for sequence, yielding up to 4096 IDs per node per millisecond. Because the timestamp occupies the high-order bits, IDs generated later sort numerically higher, giving approximate global ordering without a central sequencer — critical for systems where a monotonic id also serves as a cheap secondary sort key or cursor for pagination.

The hard engineering problem is machine ID allocation and clock safety, not bit-packing. Each generator node must hold a unique worker ID for the lifetime of its process; collisions produce duplicate IDs indistinguishable from legitimate ones downstream. Production implementations lease worker IDs from ZooKeeper or etcd at startup, or derive them deterministically from a Kubernetes StatefulSet ordinal or pod IP hash. Clock behavior is the other failure axis: if system time jumps backward (NTP correction, VM migration, leap-second smear) a node may re-emit a timestamp it already used, colliding with previously issued sequence values. Robust generators detect backward clock drift and either block/error until the clock catches up, or fall back to a persisted ‘last timestamp’ watermark and refuse to generate IDs rather than risk collision.

• Sequence overflow: if a node’s write rate for a given millisecond exceeds the sequence field’s capacity, generators must busy-wait or spill into the next millisecond, capping per-node throughput and requiring capacity planning around worst-case burst rates.
• Sharding correlation: some architectures deliberately encode a logical shard/tenant ID inside the worker-ID bits, letting a Snowflake ID double as a routing hint for database sharding — collapsing ID generation and shard lookup into one value at the cost of coupling ID format to topology.
• Information leakage: because the timestamp is embedded and unencrypted, Snowflake IDs reveal approximate creation time and, if worker IDs are guessable, approximate origin node — a consideration for public-facing resource identifiers.

Snowflake IDs sit in contrast to UUIDv4 (fully random, no coordination, no ordering) and ULID (timestamp-prefixed but using randomness instead of a sequence, avoiding the machine-ID coordination problem entirely). Systems choosing Snowflake accept an operational dependency — reliable worker-ID leasing and clock discipline — in exchange for compact, index-friendly, roughly ordered keys at very high throughput. Variants like Sonyflake (Discord) shrink the timestamp resolution or extend the machine-ID space to tune for longer node lifetimes or larger fleets, but the core tradeoff between coordination cost and ID monotonicity remains unchanged across implementations.