Note that your unique IDs like MDQ6VXNlcjM1Mjk2 don't have to be Base64 encoded; simply using user_35296 would work too. The reason they're commonly Base64 encoded is to remind users that the ID is an opaque identifier, meaning the client shouldn't manually mess with it (eg. construct an ID using 'user_' + id or anything like that) and instead just treat it as some arbitrary identifier.
Something you might find interesting is that even with the requirement of having unique IDs, Facebook still uses 64-bit integer IDs for objects in GraphQL. The reason this is possible is because the IDs are still globally unique! A fun trick is that you can go to facebook.com/{id} and it'll redirect to the correct place - This works for profiles (eg. facebook.com/731901032), Pages (eg. facebook.com/108824017345866), videos (eg. facebook.com/221489128955927), photos (eg. facebook.com/124830722411862), and pretty much everything else. The key is that each object type has a range of IDs for that object, and each database master has a range of IDs, so for a given ID we can easily tell which object type it is and which database it's located on.
You can accomplish something similar with MySQL by setting the auto_increment_increment property per session. This controls the amount IDs are auto incremented by. For example, setting it to 100 will mean the first row gets an ID of 1, the second row gets 101, the third row gets 201, etc. The intended use-case for this is master-master replication to ensure IDs between two servers don't overlap, however if you only have a single database then you can also use it to get unique per-object IDs: For example, user table can start at 1 and go 101, 201, 301, etc. and the post table can start at 2 and go 102, 202, 302, etc. Then you'd check if id % 100 == 1 then it's a user ID, if id % 100 == 2 then it's a post ID, etc.
Oh wow, that's really interesting! And really clever with the IDs 😄 also pretty... unexpected and inspiring that that works out at the massive FB scale. Makes you wonder how many similar things are over engineered in much smaller code bases.
Thanks for sharing that!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Note that your unique IDs like
MDQ6VXNlcjM1Mjk2don't have to be Base64 encoded; simply usinguser_35296would work too. The reason they're commonly Base64 encoded is to remind users that the ID is an opaque identifier, meaning the client shouldn't manually mess with it (eg. construct an ID using'user_' + idor anything like that) and instead just treat it as some arbitrary identifier.Something you might find interesting is that even with the requirement of having unique IDs, Facebook still uses 64-bit integer IDs for objects in GraphQL. The reason this is possible is because the IDs are still globally unique! A fun trick is that you can go to
facebook.com/{id}and it'll redirect to the correct place - This works for profiles (eg. facebook.com/731901032), Pages (eg. facebook.com/108824017345866), videos (eg. facebook.com/221489128955927), photos (eg. facebook.com/124830722411862), and pretty much everything else. The key is that each object type has a range of IDs for that object, and each database master has a range of IDs, so for a given ID we can easily tell which object type it is and which database it's located on.You can accomplish something similar with MySQL by setting the auto_increment_increment property per session. This controls the amount IDs are auto incremented by. For example, setting it to
100will mean the first row gets an ID of1, the second row gets101, the third row gets201, etc. The intended use-case for this is master-master replication to ensure IDs between two servers don't overlap, however if you only have a single database then you can also use it to get unique per-object IDs: For example,usertable can start at1and go101,201,301, etc. and theposttable can start at2and go102,202,302, etc. Then you'd check ifid % 100 == 1then it's a user ID, ifid % 100 == 2then it's a post ID, etc.Oh wow, that's really interesting! And really clever with the IDs 😄 also pretty... unexpected and inspiring that that works out at the massive FB scale. Makes you wonder how many similar things are over engineered in much smaller code bases.
Thanks for sharing that!