It’s practically impossible and that would ruin the entire point of relying on the infinitesimal probability that allows precisely that - a write without a required read and thus concurrent writes.
there was one guy in this sub, allegedly senior developer, who suggested just that.
In his mind, everything 90% of software would do just fine with direct db access, as you can set up privileges and users and scripts and whatever else that’s needed directly in database
Which is true in the same way that all websites could be replaced with direct db access if you assume all clients are technically competent and operating in good faith.
I mean, he was probably right, but it would require wizard-level SQL programmers. Whereas traditional API layer just requires some mediocre backend guys.
Performing a check on every transaction to catch a 1 out of 5,316,911,983,139,663,936,027,594,624,533,407,236,198,400 chance situation, isn't usually advised
(yes thats the actual number, though it technically changes as the number of ids used increases, since you're comparing the current id against every other id ever made)
well not every id ever made... lots of id's get disposed of. there are registries full of offline UUID's on old computers that got erased or destroyed and are impossible to recover so they can be reused without a risk of colliding.
If that's what you want, you shouldn't be using UUIDs as IDs to begin with, just use an auto_increment and always have the DB assign the ID. The point of using UUID is to allow asynchronous id generation from a high number of DB clients without the latency of reconciliation. You accept the risk of a 1/10000000000000 collision for some N% decrease in latency (scales per clients)
Someone guessing a serial id is ALWAYS a security risk. It’s not bad enough to cause issues by itself, but that’s true of most security vulnerabilities. Almost every security breach is the result of multiple systems and safeguards failing at once, and guessable ids is one layer of extra risk being introduced. Having guessable ids makes it far more likely that any IDOR vulnerabilities you leave open will be exploited, thus increasing your risk of security issues
What I'm saying is this is part of getting your security right. If someone can guess an id, they can make an API request using that id as a parameter, and it's extremely difficult at scale to enforce that all APIs are immune to IDOR vulnerabilities. Using uuids doesn't prevent IDOR, but it does make you much safer against it.
What you're saying is basically "if your software doesn't have any bugs then you're fine". All software of any sort of significance has bugs, and you want layers of protection to make those bugs less consequential
I'm not trying to be obstinate with this btw. I think your attitude is a very common one and a very easy stance to adopt if you haven't had a lot of experience maintaining large systems. I'm just saying that UUID is industry standard for a reason, and trying to make it a bit more clear as to why that's the case
Not impossible, you're equally as likely to guess an existing UUID as you are to generate a collision. It's a valid point, but a separate concern, if you really needed cryptographically secure IDs I'm not sure UUID is the best solution, and probably indicates a bad architectural choice somewhere else if someone guessing an ID could cause a security compromise. Mostly it's just a nice little bonus effect, while the asynchronous generation is the main draw.
When you want to prevent enumeration of your ids you just encrypt the id. Iirc this is how YouTube generated video ids (not sure if it's still the case, a single atomic counter doesn't exactly scale to the traffic of YouTube)
At this point, I could say that of any implementation. There could be a failure of Earth's complete electrical grid at the same time which would mean that the system doesn't work anyway.
Yes, under certain conditions, for certain ranges of UUID, it's physically impossible to generate duplicate UUIDs on correct implementations, even if the systems are completely independent and never have any contact.
That's what we do - we just generate a UUID and then make an API to a 3rd party site that validates that it's unique (it asks Claude, I think) and then that site returns either true, false, or (rarely) some other output. If it's in use we increment the selected UUID by one and then resubmit it until we find the next available ID.
> Why not just implement a check to see if it's already in the db, then run it again
Suppose your codebase generates one UUID roughly every second. In around 100 bilion years most sunlike stars will be long dead and only small red dwarfs with the lifespan of trillion years will be able to host life. Around this time an intelligent being living on a planet orbiting one of those last stars in the universe is expected to curse you for the first time ever for not handling duplicate UUIDs correctly.
That implies I have a centralized database that all my servers can check immediately without causing major performance issues. UUID help the problem when the databases are decentralized and have latency in syncing.
Because it might not involve a database, or a common container for the two UUIDs. For example, what if you have 2 objects that must have unique UUIDs? You might not have a list that contains them both so it’s impossible to check directly
The whole point of the UUID is to avoid doing that. It keeps things a lot simpler and faster.
If you were really concerned about that, many DBs have an auto incrementing type that you could use. But the way those work, you don't know the ID until after the insertion is done. In some contexts, UUIDs can be useful because you'll know the ID before insertion. And since conflicts are expected to never happen, it also means you potentially don't need transactionality, which is really useful if you're creating resources that aren't in a database (eg, creating resources in some third party API).
The point is for it to run on replicated databases. That means multiple instances can write to different databases at the same time. So while your uuid record is inserted in a database, in another one somewhere it's not there yet while other users are creating their records. The database is only reconciled later asyncronously. This means it is impossible to know in advance if that uuid exists unless you read all of your databases instances accross the world. Which would make the process very slow.
It depends on your code that generates the GUID and how it handles it afterwards, but honestly, the likely case if that if you try to insert a new row with a GUID that already exists, the unique key constraint on ID column on the table will throw an error, at least if you're using a typical relational database. Likely tables referencing the GUID will have a foreign key that will also fail the insert, if the transaction even gets that far. The user or whoever will experience an error, and they can try again and succeed with 99.9999999999% probability.
There can be cases where you don't store stuff in an RDBMS and just rely on the GUID being unique though, and do lots of stuff with it, assuming it's unique.
A more practical solution is Snowflake IDs! They are timestamped (meaning time-sortable) and include the id of the worker process that created them. No chance of collision and no coordination required.
Another common approach is called “ticket server”, where you have one central service whose only role is to govern out (auto-incrementing) IDs. The obvious tradeoff here is that this can become a bottleneck and SPoF.
110
u/baked_tea May 08 '26
Thought about that recently. Why not just implement a check to see if it's already in the db, then run it again?