Ask HN: Some questions on transitioning to UUID in a large ecosystem

For a content addressable file system it would be a hash, for another thing it might be an int, for another thing it might be a UUID, etc.

If you need to "validate" the ID is correct then the only way to do that is to contact the Source of Truth. Checking the syntax of the ID doesn't tell you if it is valid. That will introduce use-after-free like conditions in your system.

Part of it includes a transition to UUIDs, and the way we deal with them is slowly and in stages. Some systems, especially new ones are build to use them as the standard identification, but some of our systems are 50 years old, run on mainframes, tandem computers and what not, often with a range of APIs on top of them. Others were designed with local non-standard UUIDs that would work if the systems hadn’t been sold multiple times. And so on.

But the most basic way to get into them is by adding UUIDs for external use, while the systems continue using their own ID system internally. Then eventually replace internal IDs with the UUIDs when it becomes possible both technically and financially.

This isn’t the cleanest approach and it’ll likely take a decade or two to complete, but doing a Big Bang transition on an enterprise scale, well I wouldn’t recommend it.

As for standards, go with the newest international standard on UUIDs for you to part of the world. We follow EU.

Another possibility is to use URIs; UUIDs are URIs too! (Put "urn:uuid:" at front to make a UUID into a URI.)

For name-based or "truly random" UUIDs, you don't actually use a clock. That's only for Version 1 UUIDs. (more info in section 4.3 of RFC4122.) They unfortunately kept the names "timestamp" and "clock sequence" for both v4 & v5 UUIDs, even though there is no time-based information in them. Section 4.3 of RFC4122 describes how bytes (octets) from the name-based hash function are placed in the timestamp and clock sequence fields (for v3 & v5 UUIDs) and Section 4.4 describes how random bits are placed in the various UUID fields.

In short, you don't need to know the time to generate a v4 or v5 UUID. Having your servers synchronize their clocks is a good idea generally though; it helps make sense of log files and some protocols freak out if there's too much clock skew.

Using Version 4 UUIDs will require you to have a "truly random" number generator (or something close to it.) I wrote a node.js package for generating UUIDs and made sure it gave the user the option of using /dev/random or /dev/urandom or some other option (pretty sure I defaulted to /dev/random.) At the very least you should know the difference between /dev/random, /dev/urandom and /dev/arandom. I have used /dev/urandom as a random number source, but they were only consumed by local processes (i.e. - i didn't give them out to external clients.) So if we learned later there was a flaw in /dev/urandom, the effects would not be exploitable by external actors.

If you're dealing with financial or PII data, there may be regulatory requirements on random number generation. Heaven help you if you're recording credit card numbers in there somewhere.

It's probably hard to get detailed advice without knowing the content of the data being stored and the context of it's use. But you can plan for the worst by:

a. using UUID generation software that allows you to securely specify a specific source for your (pseudo) random numbers.

b. understand that a UUID generator might block for an indeterminate amount of time if you're forced to use a PRNG that waits to collect sufficient entropy.

c. here's my old UUID generating code. i don't recommend using it; it's just too old. but it does give an example of using an interface that lets you select the source of random numbers. it also probably doesn't work on windows: https://github.com/OhMeadhbh/node-mug