First, see the CAP Theorem. It's similar to the old aphorism of "Fast, Good, Cheap: Pick 2."
In theoretical computer science, the CAP theorem, also known as Brewer's theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:
- Consistency (all nodes see the same data at the same time)
- Availability (a guarantee that every request receives a response about whether it succeeded or failed)
- Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)
Integers
Maintaining a serialized number requires consistency... one place that is the keeper of numbers. In large systems this can become a bottleneck, a single point of failure, or both. In distributed systems, it is common to start relaxing this constraint (Consistency) in favor of the other two.
There are strategies to maintain serialized numeric identities in distributed systems, like the HI-LO algorithm or its derivatives, but it is still very possible to skip large swaths of numbers in case of node failures.
UUIDs
Another common method is to use a UUID, a randomly generated identifer (which is twice the size of Int64), which has a pretty high (but not 100%) chance of being unique from any other generated UUID. It's basically just a very large random number. This is nice for client operations, because the client can generate it with a pretty good chance of uniqueness, and subsequently use it to identify or track things. But collisions (same ID being generated) are possible (especially if the client has a terrible RNG) and still must be dealt with.
My suspicion is that the youtube identifers are some shorter variation of a uuid which is then converted to a variation of base64 without punctuation. Because punctuation kills the ability to be used in links. Hence, it's a very large number (either random or serialized) that has been converted to text so that it is shorter.
Strings
One identifier format that is fairly popular is "entity-#" or "system-entity-#" if you have a number of inter-operating systems. The # is generated either consistently by the owning system (still distributed in the sense that there are multiple systems, microservices, whatever) or with a HI-LO variation. And for display purposes, it's fairly trivial to strip off the prefix and just use the number portion.
Choosing
The above is obviously not a complete list, and in the end they are all just binary numbers on disk. The reasons to use one or the other are the architectural trade-offs that are most favorable to your system. UUIDs have the most convenient architectural properties for distributed systems, but are bad with the human factor (user can remember and type 102875, but not B9FE6378-E76C-40D5-883B-72FE376952A4, a UUID I just made).
If there is any ambiguity in what is being identified, neither UUIDs or numbers are particularly useful but strings are great there. At least serialized numbers can give you an idea of scale which can hint at what is being referenced.
There are, of course, security concerns with a string identifier like I mentioned, because it can give would-be attackers insight into your system.
I have even seen a blog post shunning numeric identifiers because of the impression it gives when a user is given low numbered resources (e.g. Account #5)... Not that I think this has merit. After all, you can always start your number sequence at 6-digits if user-confidence is a valid business concern. Edit: Trend analysis could be a security issue with incrementing IDs.