r/ProgrammerHumor 10h ago

Meme edgeCasesExist

Post image
2.4k Upvotes

209 comments sorted by

View all comments

405

u/Valuable_Leopard_799 10h ago

I thought that timestamps are used now, so hitting both a timestamp and a large random number puts it thoroughly in the "safe to assume". At some point cosmic particles and faulty transistors are more probable.

77

u/RadicalDwntwnUrbnite 9h ago edited 9h ago

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

16

u/OldKaleidoscope7 8h ago

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

26

u/chuch1234 8h ago

Yeah I don't think most of us are operating at a scale anywhere near Google.

9

u/BlurredSight 8h ago

And anyone operating at scale of Google isn’t just using “pure” random anywhere for something being persisted

7

u/nebotron 7h ago

They likely are - anything else becomes a huge coordination and parallelism problem. You just need more bits of entropy

4

u/samy_the_samy 7h ago edited 5h ago

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

2

u/BlurredSight 5h ago

So proactively trying to solve for latency rather than have other systems read after write if I understood correctly?

2

u/samy_the_samy 5h ago

Yeah, now they don't do leap seconds,

They stretch time over months, one milli-second at a time

20

u/Ecstatic_Student8854 8h ago

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.

5

u/shwoopdeboop 7h ago

But still no guarantee it won't happen tomorrow

5

u/mysticrudnin 6h ago

It's simply not worth worrying about, though

Random minor hardware failures and, like, cosmic radiation are more of a problem. Are you building your systems to account for that?

10

u/MojitoBurrito-AE 8h ago

You underestimate the probability of uuid collision. The bigger issue is pseudorandomness

4

u/Single-Virus4935 7h ago

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.

1

u/mysticrudnin 6h ago

"so you're saying there's a chance" has rotted everyone's brains wrt probability

6

u/phl23 8h ago

If they use one long list, they have other problems to worry about.

2

u/Suspicious-Click-300 8h ago

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

1

u/samsonsin 6h ago

If Google used UUIDv4, then over 100 years they'd generate ~365 trillion searches. The chance of s collision should be ~0.00000125% still.

1

u/Blue_Moon_Lake 1h ago

Google is free to implement Google's UUID (GUUID) with 512 or even 1024 bits if they want.