UUIDs: unique IDs with nobody in charge
How 122 random bits let millions of machines generate IDs simultaneously without ever colliding, and when NOT to use a UUID.
4 min read · Reviewed July 2026
Distributed systems have an ID problem: if a thousand servers each need to label new records, a central counter becomes a bottleneck and a single point of failure. UUIDs solve it with probability instead of coordination — make the ID space so vast that random picks simply never land on the same spot.
A UUID v4, the kind our generator makes, contains 122 random bits: about 5.3 undecillion possibilities. Generate a billion UUIDs per second for a century and the odds of one collision remain negligible. That's the whole trick — no registry, no server, no coordination. The format (8-4-4-4-12 hex digits) is just packaging; the randomness does the work.
Reading a UUID
The digit after the second dash tells you the version: a 4 means random. Version 7, standardized in 2024, is the interesting newcomer — it puts a timestamp in the first bits so IDs sort by creation time, which databases love (random v4 keys scatter inserts across an index; time-ordered v7 keys append neatly). New systems picking a primary-key format today should look hard at v7.
When not to use one
UUIDs are unique, not secret and not pretty. Don't use them as security tokens — 122 random bits happen to be plenty, but dedicated token generators exist for a reason and signal intent. Don't put them in URLs humans must read or type. And don't use them where a short sequential ID serves better — invoice numbers, order references. For 'many machines need IDs with no referee,' though, they're the standard answer, and the generator above gives you as many as you need.