I'm working with Google Cloud Firestore. For a particular Document ID, I'm using a modified UUID. In this modified UUID, the last 4 characters are always a string from an integer between 0000-2000.
Example IDS would be:
I'm well aware this is not ideal, and I know the last characters will repeat many times throughout the life of the database (e.g. millions of records ending in 0000, 0001, 0002)
As the database scales, will this create any major issues that I should be cautious of (e.g. hotspotting)? Or are the remaining 28 characters sufficiently unique that my lookups will not be affected despite the known duplication within the last 4?
I'm most concerned with performance at scale, and less concerned with near-perfect preservation of global uniqueness (I know I am increasing risk of duplication by going from 32 - 28 random characters).
Any sort of limits in Firestore are only triggered as a result of specific activity, including both the data being added to an index, the nature of the data, and the rate at which that data is added. There is not enough information in the question to know for sure if there will be a problem.
If you review the documentation, you'll see a stated limit:
Maximum write rate to a collection in which documents contain sequential values in an indexed field
And the limit of 500/second.
So, firstly, if you are not adding new document data at a rate of 500/second, you have no risk of exceeding any known limits.
Secondly, the limit on data being added is said to be sequential. If the trailing characters of your document IDs are not being added in a roughly sequential order (that is to say, for example, 0001, 0002, 0003, etc), then you are not at risk of exceeding any known limits.
There are no documented limits on reading/querying existing data from Firestore. You'll notice that all the limits are on write operations. I do suggest studying that entire page of documentation and compare the known limits to the expected behavior of your application.