A couple of questions about this:<p>- Why [time, node id, seq] and not [time, seq, node id]? That would improve ordering if you have approximately equal load on each box.<p>- Isn't a 16 bit seq number overkill? Handing some of those bits to the unique ID would have made unique ID assignment easier. Duplicate MACs can and do exist (especially if you buy a lot of hardware from the same vendors).<p>- The quality of the ordering is going to be restricted by the quality of time synchronization within the cluster. Relying on NTP for this is OK, but experience suggests that a secondary monitoring system will be needed. Similarly, relying on monotonic time needs some care in system administration - care that could potentially be avoided with a different unique host ID assignment scheme.
There's also Instagram's implementation in PostgreSQL:<p><a href="http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram" rel="nofollow">http://instagram-engineering.tumblr.com/post/10853187575/sha...</a>
Thanks for the interest and the feedback. I've updated the readme and added a roadmap as well as a faq after getting some good input over the last couple of days.<p><a href="https://github.com/boundary/flake" rel="nofollow">https://github.com/boundary/flake</a>
This is quite similar to the BSON ObjectId specification used by MongoDB:<p><a href="http://www.mongodb.org/display/DOCS/Object+IDs#ObjectIDs-BSONObjectIDSpecification" rel="nofollow">http://www.mongodb.org/display/DOCS/Object+IDs#ObjectIDs-BSO...</a>
For those interested, there is also Snowflake by Twitter on GitHub <a href="https://github.com/twitter/snowflake" rel="nofollow">https://github.com/twitter/snowflake</a>