I remember seeing somewhere that IDs are composed of a few pieces. I always have a hard time trying to find that information when I'm looking for it. What I mean by the above is that the various places in the ID represent different things - for example the first few characters represent what type of sObject it is.
The Id Field Type is a base-62 encoded string.
Each character can be one of 62 possible values:
As there is a combination of lower and upper case letters the casing of the 15 character Id has significance. E.g. 50130000000014c is a different ID from 50130000000014C.
Within a 15 character Id the breakdown is:
To this you can add an optional 3 character suffix that will make the Id case insensitive. This is useful when working with programs that can't maintain the case of the ID (E.g. Excel VLookup). Note this is not intended as a check sum to verify the other 12 characters haven't been corrupted.
The algorithm to convert from a 15 character Id to an 18 character Id is: (Source - I'm sure there used to be official documentation on how do this.)
In a formula there is the CASESAFEID function that will perform this algorithm.
You can apply this algorithm to some sample IDs to see how it doesn't really function as a checksum or checkdigit. For example, if you exclude the alpha characters, every ID between 001100000000001 and 001999999999999 will have the suffix AAA. Infact, you get the same suffix if you include any lowercase alpha characters as well. The suffix will only change in the presence of uppercase characters. It is basically encoding which of the 5 characters that each suffix character represents are uppercase.
If you are working with Data Exports you can also come across the special empty key with the 000 keyprefix.
One area I'm not sure of is the order in which Salesforce increments through the base 62 encoding. E.g. Does it go 0 to 9, then a to z, then A to Z? At this stage I think the sequence looks like '0123456789aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ'
The first 3 digits are a prefix that specifies the type of sObject, a big list can be found here:
I believe the rest of the Id is reference to the record itself. I should also add that the ID's are 15 digits long but can be 18 digits long with the last 3 digits for error correction making the the Id case-insensitive.
3 Digits (Object) / 12 Digits (Record) / (Optional) 3 Digits (Error Correction)
While is is true that the last 3 character ads case insensitivity, I believe the algorithm used to generate them is the check digit. Check digits originated in legacy data transmission to alleviate the introduction if errors in the data. So a bit if both I reckon.