Increment IDs or base64/hash for URLs?

Question

I've built an app where users have "rooms". Each room needs an identifier.

I've decided against using "slugs" like example.com/room/my-room-name because I want room names need to be non-unique, permanent, multi-language. I'm sure there's solutions for all this, but that's not in the scope of this particular question.

I am currently using a numeric incrementing ID (It will start at a high number on launch). I more often see base64/hash type identifiers (Example: AwqLWGibwDY) in URLs (Examples: youtube, google docs).

Is this done for UX reasons, or for technological reasons. Is there a UX reason to use a hash over a numeric id?

Answer 1

Generally, you want to avoid using auto-incrementing IDs for any public URL or code, to avoid giving out information about your application.

Consider the following scenario : I'm your competitor and I register a fake account on your website. I see that I am given the ID 172 (either by seeing it in the URL somewhere or by looking at the source code). A week later, I register another fake account and am now given the ID 184. Just like that, I know exactly how many new accounts have been registered on your website in a week. This applies for pretty much all the public resources on your website.

To avoid this, you can use UUIds, slugs or anything else than auto-incrementing ID. If for my first account I am given the ID 6653f3e9-15a109f45e3e and for the second account b445289a-4cb664e0dfd1, it doesn't expose any information about your business.

Another downside to using auto-incrementing IDs is that it gives away how popular (or unpopular) an application is. If I register on a new video sharing platform and see that the latest video has an ID of 47, I can assume that not many videos are shared and maybe I shouldn't bother. UUids or slugs don't give out that information.

Now, this doesn't mean that you should never use auto-incrementing IDs. If the ID refers to a resource that is already public (ex: the number of room in a hotel) then there's no problem with referring to room 1 with the ID 1 and room 2 with the ID 2 in your application.