4 ms·
Similar to the old situation in the article, we are using sequential 64 bit primary keys, but we use an additional random 64 bit key for external usage (instead
by dajonker 3y ago
Similar to the old situation in the article, we are using sequential 64 bit primary keys, but we use an additional random 64 bit key for external usage (instead of 128 bit).
The external key is base64 encoded for use in URLs which results in an 11 byte string.
This hides any information about the size of the data, the creation date of customer accounts (which would be sort of visible with UUIDv7) and prevents anyone from attempting to enumerate data by changing the integer in URLs.
I thought about using UUIDs as external keys but the only compelling use case seems to be the ability to generate keys from many decoupled sources that have to be merged later.
64 bit should be enough for most things https://youtu.be/gocwRvLhDf8?si=QBheJCG21bAAV0Z7 https://youtu.be/gocwRvLhDf8?si=QBheJCG21bAAV0Z7
- Waterluvian 3y agoIt sounds like you basically just made your own 64 bit UUID. If you’re exposing this ID for manual use by a human (like URLs) then that sounds pretty helpful to be shorter!
- Kunix 3y agoI am using a variant of SnowflakeId [^1] in order to have 64 bit keys too. It's similar to UUIDv7 (it leaks the creation time), but it's not an issue for me. So I am able to have a single 64 bit key, which can easily be formatted into a small string for user-facing urls. [^1]: https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c https://instagram-engineering.com/sharding-ids-at-instagram-...
- RhodesianHunter 3y agoWhat's the risk of collisions with your external ID in this scenario?