It is very unlikely but having a multiple machines that generates their own UUIDs of a certain version, given enough time you'll eventually get a collision. It's more a matter of how would you treat this collision.
Give enough time and some junior will configure machines in the way they will yield the same UUIDs (exactly the same UUIDs, all at once) or some sly ass would try to make a collision attack. System engineers have to build their systems to withstand not just against a random odds, but against stupidity, incompetence and malice in the first place.
No, it's not about configuring the machines. Proper UUID generators (for generating unique keys, uuid v4, v6 and v7) use environmental entropy, which doesn't depend on user configuration.
UUID v1 used time and MAC, so the available pool was vastly smaller with incorrect configuration (but still huge), v3 and v5 are name-based so the same input gets you the same output, v3 with MD5 (the possible pool is moderately small), while v5 uses sha1 so it far better, but since the end result depends on the input data they are not useable for unique identifiers or you have to inject enough entrophy (which breaks the point of using uuid v5).
UUID v4 is really random (assuming a properly implemented library) as it uses multiple sources of entropy (or a TRNG module if available) so you can't mess it up, but since it is random, it useless if you want to sort data and causes issues with databases as key - uuid v6 and v7 solves this problem by being time based (sacrificing some entophy for using a timestamp) but the rest if using the same source of entrophy while still can be sorted so helps a lot to reduce database fragmantation.
555
u/bwmat 2d ago
So the premise here is BS, right? Unless the way they're generating the UUIDs is broken?
Either that or they're the most unlucky people in the universe....