Id collision possibility

[gregorygauthier]

From what I understand of the code, the generation algorithm works by taking the following data in order and encoding it:

1. The version
2. The cluster worker id
3. The counter
4. The timestamp (number of seconds since the epoch defined in the code)

This creates a possibility of a collision between the following, assuming that the random numbers line up correctly:

1. An id generated with counter a and timestamp bcde
2. An id generated with no counter and timestamp bcdea

[cesni]

so, you think it's recommended to have 'short-id' like my database id(uniqueness,primary key) generator, with no collision or duplicates in some future.

[jmzhang]

This is indeed a problem, for now, the epoch is set so that timestamp minus epoch encodes to a 7-byte string, and collisions might happen when the encoded time delta bumps to 8-byte. Fortunately, it will take more than 8 years to see this happen, assuming version is never updated.