This Week I Learned: ULIDs [2022–11–18]
UUIDs are great for identifying users, requests, transactions, tenants etc etc. They are unlikely to collide, their predictable format reduces cognitive load, rules on their content avoid compatibility issues (ever try putting random strings into URLs and hoping for the best?), their ubiquity means you don’t have to explain them to everybody, and it’s great for security that they don’t reveal anything about the internal structure of your service. I remember an incident when a university used integers for student identifiers, displayed some student details on a URL containing the student id, and then students realised that if they just kept adding 1 to ids then they’d eventually be able to see every student’s details.
Would you like to be able to sort UUIDs in chronological order? Just by sorting you’d be able to see properties like which database object was created earlier, and sometimes that would work just by eyeballing them in logs or reports. Saving that extra lookup must reduce debugging time and seems like it would occasionally be good for app performance too. Avoid re-sorting or re-indexing when some new ids have been created, as the new ones won’t suddenly appear in the middle of the lexicographic order.
ULIDs do that (within a millisecond limit, but that feels generous given that you’re not usually exhausting a significant proportion of your universe of ids within a millisecond, hey).
There is a bit of thinking involved in ensuring that they have nice properties such as at least enough bits of randomness, but fortunately some folks have already done that for us. Neat!
See also:
