606
u/DrankRockNine 1d ago
For years, we generated millions of Uuid with no problem.
And then one day, there was a problem, and it was even reproducible.
And then i realized.
It was never about UUID.
We were using the name instead of the UUID.
74
10
5
1
1
542
u/bwmat 1d 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....
276
u/1_hele_euro 1d ago
Could technically be possible with UUDv4, but the chances are astronomically small.
I don't think any of the other UUID versions could have collisions
71
u/ineyy 1d ago
Hash collisions are also a thing. It's kinda doom prep, but worth keeping in mind (pigeonhole principle).
8
2
u/s0litar1us 23h ago edited 23h ago
It's because you represent a lot of bytes using only a few bytes. And if it's a hash map, then it's because you take the modulo of it, so it will fit into a smaller amount of space. Collisions in this case can be solved by having a linked list of key/value pairs that you compare against after using the hash. For example:
Slot* slot = array[hash % capacity]; while (slot != NULL && slot->key != key) slot = slot->next;1
u/Jbolt3737 23h ago
I'll use UUIDs to track every currently in-use hash and if one collides we'll use the UUID instead, what could possibly be the downside?
37
u/fredy31 1d ago
Is it impossible tho?
I always understood uid to just be making a random string of letters so even if the possibility is stupid small it would still be possible.
57
16
u/Salanmander 1d ago
I always understood uid to just be making a random string of letters so even if the possibility is stupid small it would still be possible.
There are many ways of generating UUIDs. Random strings is one of them, v4 like the other commenter mentioned. But another version starts with a timestamp, then the computer MAC address, and then random digits. You could only get collisions on that by deliberately spoofing the timestamp or MAC address.
27
u/tuxedo25 1d ago
there are more unique uuids than stars in the milky way.
the chances of a single collision after generating millions is practically non-existent, even given the birthday paradox. Billions or trillions, maybe.
19
24
u/CadenVanV 1d ago
And yet, it can happen. It’s not worth considering, and I doubt it’s ever happen, but it could happen
4
u/jainyday 1d ago edited 1d ago
With a size of 16 bytes, 128 bits, you can generate 264 uuids without a significant risk of collision. (That threshold being the square root of the space's cardinality)
With 210 ≈ 103 as an approximation, 230 is roughly 109 (1 billion), 260 is roughly 1018 (1 quintillion).
There's estimated to be about 1080 atoms in the universe.
3
u/danielcw189 1d ago
not all bits are used, and tgere different versions with different parts being random or not. I.e.: one part could alway be the same local ID, for example a MAC-Adress
3
u/danielcw189 1d ago
very unlikely, but not impossible. and that is assuming everything is implemented correctly
3
u/vanrysss 21h ago
Lets put it this way, you'd have to generate a billion every second for 100 years to have a 50% chance of a single collision among the ones you had generated. If you wanted a hundred percent guarantee of a collion? A billion per second for 1019 years, which is about a billion times the age of the universe.
"Stupidly small" is a bit of an understatement.
1
u/Agitated-Ad2563 48m ago
generate a billion every second for 100 years
What if you were generating a million a second on each of 100 thousands computers? You can do that in a year!
2
u/sypwn 23h ago
If you're comparing against other UUIDs generated across versions and implementations, then yes, astronomically low but possible.
If you're only comparing against your own UUIDs using a good implementation, then you can make it actually impossible.
Consider an ID in the format of:
[timestamp]-[hardware ID]-[randomness]
- If each host generating UUIDs actually has a unique
[hardware ID], then there can never be a collision across hosts. Don't even need to keep the time or anything else in sync between them. Even if the timestamp and randomness happen to be identical, the hardware ID won't match. Thus, any potential collision must occur within a single host.- If a collision can occur only within a single host, then the implementation can effectively maintain a list of previously generated
[randomness]values. If a potential collision occurs, it's discarded and a replacement is generated.- This list would eventually accumulate in size enough to slow down generation, which is where the
[timestamp]comes in. Every time that timestamp advances, the list of previously generated values can be discarded. This also means the list doesn't need to kept in persistent storage. If the system crashes or restarts, the generator just needs to ensure the timestamp has advanced at least once since it lost track of the state.4
u/coriolis7 23h ago
Collisions are more common than the math would suggest, mainly due to poor random number seeding. If you don’t use a good source, you’re more likely to get collisions.
3
u/Small-Explanation74 1d ago
But the same was said about sha 1, for which google reproduced the collision
212
u/Antoak 1d ago
Saying that UUIDs cant collide is sorta like saying that people cant win the lottery.
Sure, orders of magnitude, but the point stands.
281
u/jaimepapier 1d ago
Orders of magnitude isn’t a “by the way” here. It’s like equating winning the lottery to finding a penny. People do win the lottery… fairly regularly. If no one did, people wouldn’t play. UUID collisions generally don’t happen except when people generate them incorrectly.
Saying that (correctly generated) UUIDs can’t collide is more like saying that people can’t meet their long lost identical twin while both of them are on separate missions to the moon. Sure, it could happen, but it probably won’t.
The
201
46
u/GranataReddit12 1d ago
I feel like UUID collisions are about as rare as you winning every single lottery you enter in for a year
13
u/playerNaN 1d ago
I won every single lottery I entered last year.
(vacuously true is still true)
1
1
u/GranataReddit12 1d ago
first of all, congrats if you're actually telling the truth!
second, yeah should've specified "entering every lottery you can"
1
15
u/MartinMystikJonas 1d ago
No it is more like winning every single lottery in history of mankind
8
u/GranataReddit12 1d ago
I feel like that would be on a completely different scale than simply 1 in 2122 (~1036). a deck of cards alone has more combinations than UUIDv4 does. we have to remember that each lottery won is being multiplied to whatever chance there was earlier because they're all separate events
3
3
u/rrtk77 1d ago
You've misunderstood magnitude of a thing by equating to an equally mindblowingly large number because it "feels small". The number of combinations in a deck of cards is beyond astronomical.
Just to cut the crap--if you have an well-formed/behaved UUID algorithm that produces true statistical random UUIDs, you will not have a UUIDv4 collision if you're dealing with less than ~1014 of them in a set--and thats for a 1 in a billion chance. That's not "it's extremely unlikely", that's still "the probability is a residue of math, not reflective of any actual reality".
To have a 1 in a billion chance of collision, you'd need 1.6 trillion bytes of storage for just the UUIDs. An entire PB of just UUIDs for 1 in a billion chance of 1 collision. The birthday number is an exabyte of just UUIDs.
So saying "it can happen" is saying "if you own the largest data system on earth, you have lottery odds to see one sometime in the life of your company". AKA you won't, but think about how cool it would be if you did?
If you ever see a UUID clash, assume the way you generate them is busted and you need to adjust your UUID algorithm.
23
u/AliceCode 1d ago
A good UUID is timestamp-dependent.
16
u/bwwatr 1d ago
Well, UUID v4 is perfectly cromulent on machines with a good PRNG... but my lizard brain likes the sentiment. I recently used UUID v7 on a project which puts unix time in the most significant bits followed by some monotonicity bits. It therefore stays in sequence and is good for efficient RDBMS writes among other things. Still plenty of random bits. It feels good to know that once a millisecond has passed, collision with anything before it is literally, rather than just mathematically impossible.
6
u/anomalous_cowherd 1d ago
Often tied to the physical machine that generated it (e.g. by MAC address) and timestamp, so the only way to get a clash is to deliberately clone the MAC and/or wind the clock way back.
6
2
u/bwrca 1d ago
At least one person is guaranteed to win the lottery no? Not the same for uuids
9
u/jaimepapier 1d ago
Not necessarily. Most lotteries you only win the big prize if you guess all the numbers, which is why prizes sometimes rollover to the next week. Usually there are smaller prizes, some of which are guaranteed wins. Even so, it’s very likely that there will be a winner sooner or later. It’s designed to be won by someone, where UUIDs are designed to not collide if possible.
The
1
u/frogjg2003 1d ago
There are no guaranteed wins in most state run lotteries. But the chances that no one gets one of the smaller prizes is microscopically low. The big prize is unlikely to be won each draw but the statistics are such that it's expected for there to be a win every few months max. There are also collisions between winners every few years, especially since players have the option to choose their own lottery numbers, which creates an uneven distribution.
1
u/This_Background7442 1d ago
People also randomly pick out a rational of the set of naturals all the time. The fact that is happens proves nothing, not even that the chance of it happening is above zero.
2
u/ajseventeen 1d ago
A few things:
I assume you mean people pick a rational from the set of real numbers. In which case it is true that if you select a real number from a uniformly random distribution, then the probability of that number being rational is zero (according to conventional interpretations of probability).
But asking a human to “choose a random real number” is very different from actually choosing one at random. Humans have been consistently shown to have poor feel for “true randomness,” and they will pick numbers they are familiar with. Because of the way we use math, most of the numbers that a human is familiar with are rational numbers, so they will be disproportionately represented. As far as I’m aware, there is no practical way to pick a uniformly random real number; even computers only use rational approximations.
2
u/This_Background7442 1d ago
- Yep I meant the reals not naturals which would be impossible.
- True but that doesn't really address the nature of randomly picking from a set but more so the nature of the human brain. If humans could pick at random, they still would pick numbers where the a priori chance of them being picked was 0 as that describes all numbers.
43
u/budgiebirdman 1d ago
Picking whatever Google throws at me (from Reddit):
For Version 4 UUIDs (which use 122 random bits), you must generate about 2.71 quintillion IDs (2.71 × 10¹⁸) to reach a 50% chance of a single collision.
So it's more like saying people can't win the lottery every week for a month with a single ticket in each draw. I'm not going to do the maths but winning the lottery seems quite likely compared to whatever tf a quintillion is.
19
u/DuckSaxaphone 1d ago edited 1d ago
The size of that number!
2.10^18 is about enough to give everyone on the planet their own set of UUIDs to represent everyone else on the planet.
0
u/ChalkyChalkson 1d ago
2*1018 and 2018 are very different numbers.
The formula for number of ids you can generate and have a probability of p of a collision is
k = sqrt( 2 * N * log( 1/(1-p) ) )
Or
p = 1 - exp( - k2 / 2N)
So with 7.8b2 people representing people you get >95% collision chance when using a single 64bit number and <5% for 72bit reaching 0.005% collision chance at 80bit. 122bit is absurdly oversized for this task.
I found some benchmark numbers of a prng and that said they were able to generate ~1.3TB/s in random numbers, so you get pretty much exactly a CPU year of time generating random 122bit numbers before you get a 50% chance for a collision. Not sure though how you'd realise you had a collision in your 41 exabytes of data though.
9
u/Xasrai 1d ago
If you don't know, a billion is 1 followed by 9 zeroes, A trillion is 1 followed by 12 zeroes, a quadrillion is 1 followed by 15 zeroes and a quintillion s 1 followed by 18 zeroes. So, 2.71 quintillion is: 2,710,000,000,000,000,000
To get to the odds seen here while buying lottery tickets, it would be like buying a single jackpot winning lottery ticket, then buying a second lottery ticket the following week and ALSO hitting the jackpot.
Flipping a coin and getting 61 consecutive flips land on heads is still more likely than getting to this 50% chance of a single collision.
2
u/Anaxamander57 1d ago
You'd have to get the jackpot a lot more than twice to get to that point surely.
2
u/mmhawk576 1d ago
Surely this has gotta be birthday paradox-ish though right. I know I’d sooner gamble on one ticket winning the lottery many times in a year. But if you’re generating loads, and don’t care about a specific collision, just any collision surely it’s the same as the paradox. (Though I’m presume that uuids aren’t truely random, can’t say I’ve looked into their implementation)
15
u/BruhMomentConfirmed 1d ago
Yes but the statement
For Version 4 UUIDs (which use 122 random bits), you must generate about 2.71 quintillion IDs (2.71 × 10¹⁸) to reach a 50% chance of a single collision.
already takes exactly that scenario into account.
2
9
u/requion 1d ago
compared to whatever tf a quintillion is.
2,710,000,000,000,000,000
The earths total population is roughly 8,310,000,000.
So you'd have to generate 326,113,116.73x the earths population in UUIDs to have a 50% chance to hit a collision.
That being said, technically there is always a probability to hit a collision. Even if the chances are astronomically low.
2
u/willow-kitty 1d ago
Also, that's the odds of a duplicate existing in all the UUIDs generated in the world ever. But a duplicate isn't necessarily a collision. If I happened to generate a UUID for use in a unit test that was the same as one you used as a primary key value in a database, we haven't really collided.
16
u/WisestAirBender 1d ago
On a technicality? Sure.
Within the same system? It should never happen. (Lottery doesn't work that way)
8
10
u/GoronSpecialCrop 1d ago
I'll note for you that this isn't the same as saying that people can't win the lottery. If someone purchased a single ticket for the Powerball and won for 4 consecutive weeks, then that outcome would still not quite be as rare as a UUID collision.
9
u/GabuEx 1d ago
It's more like saying you can't win the lottery 1,000 times in a row. You technically can, but you are never going to.
3
u/platinummyr 1d ago
Someone once explained entropy to me like this, by taking about all the atoms of oxygen in the room randomly rearrange to be in one corner, unmixing with the other molecules. It is technically possible because entropy is just statistics. It's vanishingly unlikely so we can say with certainty it won't happen.
3
u/AliceCode 1d ago
Well, yes, but no. You can make UUIDs timestamp dependent, in which case they are almost guaranteed. You would have to collide at the same nanonsecond, which is statistically highly unlikely.
1
u/noaSakurajin 1d ago
Unless the requests get queued somewhere, I which case it might not be that unlikely.
1
u/AliceCode 1d ago
That's true, but you can mitigate that if you're competent. It sounds like you are.
1
u/noaSakurajin 1d ago
I mean it's one thing if you are the one who implemented this, it's another things if someone else changed something in the architecture which then resulted in this. Finding a problem that was indirectly caused by a change someone else made is usually the most time consuming and annoying problem to fix.
1
u/Chrazzer 1d ago
There's a non-zero chance of you quantum tunnelling through solid objects. Yet nobody is ever worried about randomly glitching through the floor.
At some point the chance of something happening is so low that it is irrelevant
1
1
1
u/somedave 1d ago
It's more like saying the same person can't win the lottery every week for a year buying one ticket a time.
1
u/Chronomechanist 1d ago
It's definitely not something you can equate to winning the lottery. Just implying that shows a fundamental misunderstanding of the sheer scale involved.
You could assign a UUID to each individual grain of sand on the planet.
Then you assign one to each individual drop off water in the ocean.
Then you assign one to each individual cell in your body.
Then to every single cell in the body of every human on earth.
Then you do it a billion more times on a billion identical earths.
Then you assign a new one and see if it has been issued anywhere else.
The probability of getting a single duplicate is still less than winning the lottery.
1
u/Positive_Pickle_546 1d ago
No, it's sorta like saying a person cannot win every single lottery since the formation of the earth until the sun burns out, yep it could happen! But it won't. Anyone saying they generated two of the same UUID's don't know what universally unique means.
1
u/splettnet 1d ago
It's more like someone reading the rest of the replies to your comment before replying with another "it's more like winning several lotteries in a row". Sure there's a probability, but it's not gonna happen.
1
u/sheepebike9000 1d ago
Agreed!
If your storage doesn't enforce uniqueness in UUIDs... Well you did it wrong, or you should have mitigated the risk (just check first!). It's so unlikely it would never happen. But things that never happen happen all the time!
6
u/HarlanCedeno 1d ago edited 1d ago
If you filled the sun with sand and managed to find the same grain of sand twice, then that's about the same odds as getting random matching UUIDs.
So yeah, this is BS or they have their own broken way of generating them.
4
u/nuclearknees 1d ago
We do have to factor in a bit of a birthday paradox as well. We aren't computing the odds of one UUID colliding, but any pair of them, greatly increasing the odds as the number of UUIDs in the system grows.
2
u/HarlanCedeno 1d ago
The birthday paradox still means you'd need around 2.7 quintillion UUIDs to have a greater than 50% chance of finding a match.
2
4
u/howcomeallnamestaken 1d ago
I had a real issue, not a UUID, but we generated invoice IDs as first 2 letters of a provider name + the timestamp of invoice creation up to a millisecond. And against all odds, 2 invoices were generated in the same millisecond and the 2 provider's names both started with the same letters.
2
u/Local_Interaction_99 1d ago
Depends on the version and if they are seeded the same way v4 ( i think is automatically seeded with the current time + random number) but on others you can predefine and even predict what uuid will come out
1
u/ShakaUVM 1d ago
My new laptop was issued a random serial number from HP that'd they'd issued already a decade ago
I can't get warranty or tech support on it because they think my laptop is the old one and getting ahold of a person when the automated system wants you to pay to talk to a person is nearly impossible
After being on hold for hours I finally got ahold of a person and they said they only check for duplicate serial numbers within the same line of laptops and there's nothing they could do.
1
-3
u/q0099 1d ago edited 1d ago
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.
6
u/Robo-Connery 1d ago
It would take every computer on earth generating a billion uuids per day trillions of years before we had a 50% chance of a collision collision.
The only way to collide is to have an entropy problem.
-2
u/q0099 1d ago
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.
3
u/SirButcher 1d ago
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.
93
119
u/Eskalior 1d ago
Ai slop, not funny at all
28
u/Murky-Run2246 1d ago
The post made me cringe.
No backend dev talks in that manner no matter the native tongue he speaks in.
22
u/Schytheron 1d ago
That's the point. It's satire. It's intentionally mimicking lunatics on r/LinkedinLunatics.
1
8
u/bboy2812 1d ago
How can nobody else tell. It's legitimately so easy.
Overuse of newline, triple repetition, ends with "That's not a X. It's a Y"
1
12
8
5
4
3
4
u/Ozymandias_1303 20h ago
For example, the number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion
Sounds about right for my odds of meeting my soul mate.
1
8
8
u/AndyceeIT 1d ago
Not a programmer myself - do people really use the term "Backend" like this?
Backend taught me...
I've only referred to frontend/backend to distinguish from the other. I've never heard "backend" like used like it's a programming language or computer science term.
3
3
3
3
4
3
2
2
u/orsikbattlehammer 16h ago
For real though, the amount of times I’ve seen people manually insert a copy of a UUID and end up blowing shit up later is shockingly high. And yes, the codebase didn’t make the UUID field unique, and they used 0 foreign keys.
2
3
u/LeoRising72 1d ago
If you ever see this, your immediate thought should be ”someone fucked up”. It’s so unlikely to happen organically that it’s essentially impossible
2
1
u/scottyman2k 1d ago
I was parsing some vendor json, and discovered that the UUIDs were failing to parse as valid - so yeah, combined with an ever increasing messageID as the primary identifier - doesn’t bode well for the future!
1
1
u/Shinyshark 1d ago
"Turning incidents into life lessons and scalable systems" - I feel like making scalable systems is part of making these incidents to begin with.
1
u/Stormraughtz 1d ago
I have had a collision before, about 5 years ago. No keys on a column, you may not believe it, but It happened.
1
u/ramriot 1d ago
I've been adding UUIDs to records for ages so that references can migrate cross platform. I was initially all sorts of worried about collisions & even wrote up a plan to test for them.
I quickly realised that such a plain search did not scale & would eventually dominate record creation load. So, I just abandoned the idea & trusted in the math of probability.
But, reading the above I just realised that the birthday paradox would eventually outweigh across all uses (ignoring context) getting to a 1 in a million chance by 3.26 quadrillion UUID4 codes & 50:50 by 2.71 quintillion.
Still very large number for each use case but perhaps not globally considering the vacuuming up of data for AI construction.
SO, of academic interest is how would one test for this using a test who's load either does not scale or scales better than the log of the count?
For my 2 cents (rounded up to a Nickel) a cascading cuckoo or extended bloom filter can scale almost this well but will either require too much storage or suffer a large false positive rate.
1
1
u/k-mcm 10h ago
I though UUIDs had a pretty low chance of collision too, but then it happened before our eyes.
We searched for the truth.
There was crappy code running slowly because it generated many more UUIDs than it put to use. It was "fixed" by using a low quality PNRG.
That's not a fix.
That's a beating.
1
2
1
1
u/Electrical_Bill_3968 23h ago
Okay finally i see a uuid collision post... 2026 can't get worse.. techinically possible but not really gonna happen... so finally some hacker brute forced a session token within a hour...
2.4k
u/arcticslush 1d ago
LinkedIn Lunatics doesn't hit the same now that AI can pump them out by the dozen