On: Show HN: Decentralized, k-ordered unique IDs in Clojure

That's one reason you'd want this. A few others that I can think of:

* No single point of failure if the id server goes down * Avoiding network round trip latency * You have distributed servers across multiple data centres (though clock sync may be an issue)

If your service can tolerate k-ordered ids then I would pick this over a central server every time.

Another alternative is using local UUIDs, right ? If you're just interested in generating a unique ID to shard and insert into one of your DB nodes.

UUID 1 contains time values but arranges the UUID parts in such a way that the k-ordering is lost. But certainly if you just need an opaque id then a UUID would be fine. https://en.wikipedia.org/wiki/Universally_Unique_Identifier#...

The disadvantage a UUID has is that they're larger, Snowflake was something like 63 bits, UUID is 128, 2x as long.

Snowflake was 63 bits due to some cleverness with resetting the epoch and coordinating unique worker ID's through Zookeeper.

These Flakes relax those restrictions and are 128 bits. The benefit is that they don't require a central server to distribute worker ID's and the epoch is the standard Unix epoch. This holds as long as the MAC addresses on your machines are unique. As another commenter mentioned, this doesn't always happen.

UUIDs also don't generally havea notion of ordering.