Has Salesforce hit an architectural limit?

And it all started from a Tweet this morning:

Learn’t something today… anyone know what the 4 character of #Salesforce ID represents? EG 003 = Contact but whats the next character? 🙂

— Francis Pindar (@radnip) January 26, 2015

But it got me thinking. But first for a bit of background:

Sometimes when you are developing in Salesforce you need to identify what object a record relates too. You can do this quite simply by looking at the first three values of the record Id. For example: 001g000000PM12O you know this is an Account record because the first three characters are 001 which is the identifier for the standard Account object in Salesforce. Salesforce a handy page “Standard field Record ID Prefix Decoder” to identify these. But do you know what the 4th character is used for?

Whats the 4th character in a Salesforce record ID?
Well the 4th character in the record id is the server id. This identifies the server on which the record has been created. So in my account id example above you will see the 4th character is a g (001g000000PM12O). The character g represents instance CS17, D = NA1 and so on…

So that peaked my interest as only having one character to determine the instance essentially means you have a maximum of 62 possible combinations:

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

and it JUST happens that currently there are 61 instances live on trust.salesforce.com… plus the pre-release org means 62 current instances, can anyone see an issue here? 🙂

Has Salesforce now hit a architectural limit on the number of instances it can create?

Does this mean that our 15 digit IDs are about to increase to 16? 18 digit ids to 19 etc…?

But actually locking a record down to an instance/server may have made a little bit of sense when Salesforce was first conceived (to easily route traffic to the correct servers), but not so much now. In fact there are certain operations that break this. If you create a new sandbox the id’s are preserved from your production organisation (except the sandbox’s new org id). So actually you can have records with different server id’s to the instance the org is running on.

Salesforce could break the reliance of the 4th character being tied to an instance. But there could be a potential fly in the ointment. What customer code currently relies on it?. For example Salesforce Workbench, has code that references the server id’s, and Salesforce StackExchange has questions answering giving this as the example so people are using it.

In conclusion I doubt it will be a big issue. The great thing about cloud computing is Salesforce can be beavering away under the covers to re-architect parts of Salesforce to fix these architectural challenges and we are completely oblivious to them. Yes some customers will be impacted (maybe) when Salesforce removes the reliance on the 4th character being a server id. On the plus side it increases the id pool for everyone else, but that does beg another question but thats for another time 🙂

I leave with a warm fuzzy feeling that even the big companies can get it wrong and have to deal with legacy architectural designs, sometimes 🙂