# Generating unique IDs: an easy and reliable way

DevFeed: [Generating unique IDs: an easy and reliable way](<https://devfeed.tech/articles/generating-unique-ids-an-easy-and-reliable-way-20690.md>)

Original publisher: [Read original article](<http://antirez.com/news/99>)

Published: 2015-11-21T14:47:01Z

Content type: tutorial

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [V8](<https://devfeed.tech/topics/v8.md>), [math](<https://devfeed.tech/topics/math.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>)

Tags: [ids](<https://devfeed.tech/tags/ids.md>), [math](<https://devfeed.tech/tags/math.md>), [processes](<https://devfeed.tech/tags/processes.md>), [v8](<https://devfeed.tech/tags/v8.md>)

## AI overview

The article discusses weaknesses in V8's Math.random() implementation and presents generating uniformly distributed random numbers from a sufficiently large range as a practical way to make ID collisions highly unlikely. It contrasts this approach with stateful counters and process-specific prefixes.

## Source excerpt

Two days ago Mike Malone published an interesting post on Medium about the V8 implementation of Math.random(), and how weak is the quality of the PRNG used: http://bit.ly/1SPDraN. The post was one of the top news on Hacker News today. It's pretty clear and informative from the point of view of how Math.random() is broken and how should be fixed, so I've nothing to add to the matter itself. But since the author discovered the weakness of the PRNG in the context of generating large probably-non-colliding IDs, I want to share with you an alternative that I used multiple times in the past, which is fast and extremely reliable. The problem of unique IDs - - - So, in theory, if you want to generate unique IDs you need to store some state that makes sure an ID is never repeated. In the trivial case you may use just a simple counter. However the previous ID generated must be stored in a consistent way. In case of restart of the system, it should never happen that the same ID is generated again because our stored counter was not correctly persisted on disk. If we want to generate unique IDs using multiple processes, each process needs to make sure to prepend its IDs with some process-specific prefix that will never collide with another process prefix. This can be complex to manage as well. The simple fact of having to store in a reliable way the old ID is very time consuming when we want to generate an high number of IDs per second. Fortunately there is a simple solution. Generate a random number in a range between 0 and N, with N so big that the probability of collisions is so small to be, for every practical application, irrelevant. This works if the number we generate is uniformly distributed between 0 and N. If this prerequisite is true we can use the birthday paradox in order to calculate the probability of collisions. By using enough bits it's trivial to make the probability of a collision billions of times less likely than an asteroid centering the Earth, even if we g