Database ID Generation

It is incredibly unlikely but you're right, especially when there might be poor UUID generators being used. We use 64-big ints for all ids which are resereved as batches from a global id service. Any datastore with atomic increments can serve this so I'm surprised it's not used more often.

Creating ever increasing ids reliably at scale is not trivial. You will probably end up having a single server generating these ids which will then become a single point of failure.

Don't they have the same problems the article dislikes about auto increment numbers?

this is exactly what they have done in their new ids and the snowflake system. They have a timestamp, a sequence number and a system identifer, plus a few neat properties.I don't think they can be blamed for using a trivial incremental key when they had 10 users, I am sure they were not expecting to have 200M :)

The risk with an incrementing integer is that your database falls over then you can lose some IDs depending on how often you take backups. After you restore you need to make sure that whatever integer you start at is greater than the highest integer issued beforehand, which may be different to the highest integer in your restored DB. Otherwise you can have clients with the same ID.

The solution is to stop using auto-incrementing IDs generated by the database, and UUIDs are not the only answer.It is trivial to have an app request and reserve a pool of IDs and assign from them as needed. It guarantees no overlap, is completely distributed, requires no db roundtrip to insert, can remain as numeric data, allows every row to be uniquely identified across tables or databases, still has loose ordering, and it only requires a system with atomic increments to implement.

How did you handle the autoincrement id problem with distributed databases? Did you replace them with hashes?

A better tip would be to use something like time-ordered uuids: You can‘t misuse them for something different and the added bonus is that no one can iterate your db records by just incrementing the url.

Haven't they ever heard of a UUID? Or if they are worried about potential collisions at least make the number 128bit (since you have an obscenely large max value to increment to).

this is when uuid would be nice, or at least 6+ digit non-sequential ids...