Comment by jandrewrogers
19 hours ago
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.
Only expensive if you have unsorted keys or lack an index. Neither of which are unscalable.
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.
No I didn't miss it.
DynamoDb works fine, using CQRS if necessary.
2 replies →
AKA centralising a decentralised identifier generator?
There are better approaches like pre -avoiding collisions but generating tends to be more expensive than checking.
2 replies →
exactly lmao. that is exactly what is being presented as "scalable <full stop>". sigh.
1 reply →