The maximum number of asynchronous Apex method executions (Batch Apex, future methods, and scheduled Apex) per a 24-hour period is 250,000 or the number of user licenses in your organization multiplied by 200, whichever is greater
for more reference check this link
The parity bits are meant to help systems that ignore case sensitivity to properly find records where the short Ids differ only by case. For example, SOSL can't tell between case, so if you're logging Ids into a text field, the long Id will correctly find just the records you want.
It does not mean you can, or should, freely modify an Id's case. It simply means that systems that can't tell between lowercase and uppercase, usually as a convenience to users, won't match up records incorrectly.
In general, you should always prefer to use the long Id when possible, as it increases interoperability with various systems.
As an example, consider these two ID values:
0019000001AWn2oAAD
0019000001awn2oAAA
If you were to use just the 15-character form, they then look like this:
0019000001AWn2o
0019000001awn2o
If you try to compare them in Excel, you get an "unexpected" result:
="0019000001AWn2o"="0019000001awn2o" (TRUE)
This makes normal VLOOKUP functions fail, because Excel doesn't normally care about case sensitivity.
However, using the long version:
="0019000001AWn2oAAD"="0019000001awn2oAAA" (FALSE)
Solves the case insensitivity issue. This allows the external system to properly match up records when it considers uppercase and lowercase to be an equal value.
Best Answer
From my observation, UserInfo.getUserId should always return an 18-character ID. However, the return type is "String" for this method, so there is no guarantee that the return value will always be the 18-character ID format. However, you can guarantee that an ID will always be 18-characters if you use the Id data type:
This works because the Id type automatically validates the String is a valid ID and automatically calculates the parity bits for the ID (the last three characters).