When are you truly forced to use UUID as part of the design?

Question

I don\'t really see the point of UUID. I know the probability of a collision is effectively nil, but effectively nil is not even close to impossible.

Answer 1

Aside from cases where you have to use someone else's API that demands a UUID, of course there's always another solution. But will those alternatives solve all the problems that UUIDs do? Will you end up adding more layers of hacks, each to solve a different problem, when you could have solved all of them at once?

Yes, it is theoretically possible for UUIDs to collide. As others have noted, it's ridiculously unlikely to the point that it's just not worth considering. It's never happened to date and most likely never will. Forget about it.

The most "obvious" way to avoid collisions is to let a single server generate unique IDs on every insert, which obviously creates serious performance problems and doesn't solve the offline generation problem at all. Oops.

The other "obvious" solution is a central authority that hands out blocks of unique numbers in advance, which is essentially what UUID V1 does by using the MAC address of the generating machine (via the IEEE OUI). But duplicate MAC addresses do happen because every central authority screws up eventually, so in practice this is far more likely than a UUID V4 collision. Oops.

The best argument against using UUIDs is that they're "too big", but a (significantly) smaller scheme will inevitably fail to solve the most interesting problems; UUIDs' size is an inherent side effect of their usefulness at solving those very problems.

It's possible your problem isn't big enough to need what UUIDs offer, and in that case, feel free to use something else. But if your problem grows unexpectedly (and most do), you'll end up switching later--and kick yourself for not using them in the first place. Why design for failure when it's just as easy to design for success instead?