News for hackers. Stuff that matters.

A comment on Ask HN: We just had an actual UUID v4 collision.... Parent comment

Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @03:35PM (#48067687)
Super simple to detect and try again.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by jandrewrogers on Friday May 08, 2026 @03:58PM (#48067946)
A collision is simple to detect but it requires you to actually check, which is expensive at scale. The entire point of UUIDv4 is that you don't have to check for collisions because it should never happen. But if you don't check and it does happen you are in UB territory which is generally very bad.

A risk of collision before it happens is non-trivial to detect but this is really what you'd want.

[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @06:49PM (#48069713)
Only expensive if you have unsorted keys or lack an index. Neither of which are unscalable.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by jandrewrogers on Friday May 08, 2026 @07:06PM (#48069870)
You must have missed the “at scale” part. There is nothing inexpensive about extra network hops, cache misses, and page faults implied by your solution. Indexing at scale is almost always lossy for performance reasons. The location where you insert a new record is frequently not the same location as where you have to search for an existing record.

It is resource amplification all the way down. In a lot of systems that index these keys the cost of that check is several times that of doing a blind insert.

[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @07:10PM (#48069900)
No I didn't miss it.

DynamoDb works fine, using CQRS if necessary.

[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by keeganpoppen on Friday May 08, 2026 @07:52PM (#48070204)
literally the whole point of randomly generating UUIDs is that you don't need to check for collision. that's what the "U"s are for. that is the abstraction that is supposedly being provided. "using <insert Amazon AWS Certification Test Answer #7>" is not in any way a "scalable solution" for that with no other context. nor is just throwing out <random Martin Fowler concept #27>. the whole point is that it is a global (well, per name, "universal") abstraction that can, in practice, have holes that make it so you can't use it "universal"-ly.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @08:08PM (#48070319)
I totally appreciate what you are complaining about. It's always been part of the documentation for a UUID. Having had Martin Fowler as a colleague and meeting with him weekly for a bit, I'd expect him to nod along with what I've written. It's standard knowledge and part of the technical corpus. As is actually distributed unique ID generation which is also not hard.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by keeganpoppen on Thursday May 21, 2026 @05:19AM (#48219900)
well it’s especially not hard when you turn it into a completely different problem
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by orf on Friday May 08, 2026 @07:06PM (#48069867)
AKA centralising a decentralised identifier generator?
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @07:12PM (#48069911)
There are better approaches like pre -avoiding collisions but generating tends to be more expensive than checking.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by orf on Friday May 08, 2026 @07:14PM (#48069932)
In what world is generating a UUID more expensive than checking for duplicates? at any scale?

Walk me through that please

[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @07:18PM (#48069963)
Yeah, that was a little sloppy but it's generating is more expensive than not generating. In more words, generating an id and validating uniqueness is more expensive than only validating uniqueness.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by soni96pl on Monday May 11, 2026 @05:39AM (#48092898)
UUID is used where checking is difficult, think distributed devices offline at a plantation. How could checking be easier in that case? It would require infrastructure that doesn't exist. There are many other cases where it's easier to handle collisions.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Monday May 11, 2026 @09:46AM (#48094950)
Agreed. While it's an uncommon scenario it is a significant case and UUID shouldn't be used in that case because as you write checking doesn't work well. Better to use an alternative such as coordinate/reserve monotonic producer IDs that get paired with monotonic, per-producer monotonic sequence IDs to produce guaranteed unique, well-ordered IDs.

[edit: in IOT it's common to issue x509 certificates as a type of authentication which could be used instead of using producer IDs. Solutions always have to be paired to use case.]

[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by tommoneytools on Monday May 11, 2026 @05:42AM (#48092912) 

   Wild edge case. Curious if they ever found the root cause.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Monday May 11, 2026 @09:49AM (#48094987)
Welcome to Hacker News.

I suspect you meant to reply to a different comment. Regardless the most plausible speculation I've read here is that the RNG used to generate the UUID is low quality.

[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by keeganpoppen on Friday May 08, 2026 @07:53PM (#48070216)
exactly lmao. that is exactly what is being presented as "scalable <full stop>". sigh.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @08:12PM (#48070344)
No one has yet defined the scale but almost all of the real world scenarios people are actually encountering would be handled by either of the offered solutions.
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by keeganpoppen on Thursday May 14, 2026 @04:09PM (#48140575)
as would be a million things that don’t involve using uuids at all. it literally means nothing to say “this can be handled by centralizing your uuid store”… if you do that, you DON’T NEED UUIDS. THAT IS THE POINT!
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Thursday May 14, 2026 @04:23PM (#48140736)
You seem to be insisting that UUID meets the promise of it's name, despite the long standing documentation to the contrary. Is that your intention?
[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by squirrellous on Friday May 08, 2026 @10:36PM (#48071214)
In this specific case. In the case of trace IDs (an example of which is [1]) where the equivalent of UUIDs are explicitly used to avoid coordination, it’s hard to imagine how you’d reliably detect and retry.

[1] https://news.ycombinator.com/item?id=48033853

[ Parent | on HN ]
Re:Ask HN: We just had an actual UUID v4 collision... by erikerikson on Friday May 08, 2026 @11:45PM (#48071630)
A lot of databases have a uniqueness constraint that is basically a register level compare and replace. Others have a if_not_exists which is nearly the same. If you're not targeting a serious throughput use case, it's enough. If you are then there are lots of solutions/alternatives that completely avoid coordination. On the other hand, maybe tracing protocols are robust to out of order delivery. If that won't do them sequence numbers tied to monotonic sequence IDs should be plenty. If not then I'd need very serious conversations to be convinced you're not wasting everyone's time
[ Parent | on HN ]