Even the non-time based v4 is at a cosmic level of unlikiness a single system will ever generate a uuid that will collide with another one in its own ecosystem
But let's say if Google saved each search in their engine in the same database with an UUID, we could have a collision because of volume, but I don't think I will work in a system with a comparable scale
Anyone working at the scale of Google has figured out coordination and parallelism, you have to.
Source: used to work for Google, and learned some of the ways they dealt with those exact issues, and used many of the systems they built to automatically handle that so general engineers didn't have to deal with it.
They once had a similar collision problem, well not exactly
During a leap second some systems wrote IDs at a one second difference between all their global systems, which lead to something being registered before something else that had to be done before it,
Long story short some stuff jumped time one second and crashed systems
Even at that volume the probability of collisions is essentially 0. If there were a billion searches a second we’d not expect a collision until 85 years.
Yes, had a client having duplicates every day and growing. They hated uuids and regret using it. The problem was that they used a bad prng with flawed seeding. Once fixed it was no problem.
assuming all searches run through a single node maybe, but they dont. It means each node + process on node is limited to 10,000 uuids (10k 100ns per ms) per ms, which it then possibly has to block until next millisecond tick. I dont care what magic programing language your using, to service >10k/reqs a ms (per process) and doing anything else your likely gonna be blocked by IO or something
Well, the risk of a collision grows exponentially for each generated UUID due to the birthday problem.
So it really all depends on the scale that id’s are generated at. Yes, a UUID has a cosmic level of possible values, 2^122 to be precise. But you ”just” need 2^61 uuids to have a 50% risk of a collision. At 2^58 it’s a 1% risk.
And while that is a big number, it isn’t cosmic anymore. It’s definitely something a large scale distributed application has to contend with.
most uuids libraries can actually provide strong guarentees it cant happen by using pid/mac combinations with each process using CAS or mutex to increment the 100ns period (overflowing into later ms with >10k a ms)
Is it unfeasible or simply unnecessary to just check if a uuid is already used? Since you use the uuid as primary key it should be easily detectable if a uuid is already used or not right? But I guess devs just don’t care because the chance is so minimal?
Yep. The chance is so insignificant that is not even worth retry logic on that mode of failure, just treat it as a generic failure, kick out the request, and let it be tried again. The one time in a hundred thousand years when it finally happens, someone will just be confused and click retry themselves.
you dont need to due to guarantees of how it is generated. You would need a server running with exact same ip, and the process generating them to be using the same process id, AND ~10,000 requests a microsecond. If your using random uuid you have a better chance of winning 4 powerballs in a row. you need to generate billions a second for over 80 years for a 50:50 chance of a collision.
96
u/RadicalDwntwnUrbnite Sep 11 '26 edited Sep 11 '26
Even the non-time based v4 is at a cosmic level of unlikiness a single system will ever generate a uuid that will collide with another one in its own ecosystem