Lila: game id collisions

[niklasf]

We're picking randomly from 54^8 possible game ids with 500 millions already taken.

@cyanfish gave a nice and simple way to estimate the number of collisions in a month (given that the games played in the month are only a small fraction of the games that have ever been played): Just calculate number of games per month * 500 million / 54^8.

With 40 million games per month, that means we're expecting to see well over 200 collisions per month, now.

Possible solutions:

• Longer game ids (for example of length at least 12) would make collisions extremely unlikely.
• Adding more characters to the alphabet of game ids [0-9a-zA-Z].
• Probably simpler: Checking if a game id already exists (probability of race conditions is neglegible) before assigning it. This should be sustainable for a long time.

[BrandonEvansAsurion]

Any reason not to use UUIDs going forward?

[cyanfish]

Game ids are part of the game urls, so UUIDs would make the urls unnecessarily long.

[aeisenberg]

Another possibility would be to use an increasing numeric value. This presupposes a centralized database that all clients can query to determine the next game id.

[BuonOmo]

You could as well have an id with a time reference. For instance <yyMMddhhmm><random-string>, so the 12/26/2018 at 13:18:29 you would have _181226131829azEB_. There is a similar implementation in MongoDB's ObjectID.

The point is you have fewer collisions, and your ID has more pieces of information.