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 🙂
UPDATE: Steve Tamm (CTO of Salesforce) has confirmed they have known about this for several years and actually sorted it several years ago (see comments below). Now they support up to 238,328 instances. I think it will take a while to fill those 🙂
Daniel Ballinger
January 26, 2015 at 7:44 pm
At a guess, I’d say it will spill over into the 5th character. nnAlso, I don’t think that having the pod identifier in the Id is anything more than a convenience. Orgs can be migrated from one pod to another with the IDs unchanged.nnBecause of this migration it’s always been risky to base any functionality on the pod id.nnThe best use case I’m come up with is distinguishing between a sandbox and production org using the org id.nnSee also http://salesforce.stackexchange.com/questions/64392/what-will-happen-with-the-salesforce-pod-identifier-when-there-are-more-than-62
What will happen with the Salesforce Pod identifier when there are more than 62 instances? | DL-UAT
January 26, 2015 at 7:50 pm
[…] per Has Salesforce hit an architectural limit?, there are currently 61 pods listed on […]
Mary Pustejovsky
January 26, 2015 at 8:26 pm
Interesting. I imagine if you asked Stephen Tamm he would be willing to discuss.
Radnip
January 26, 2015 at 9:24 pm
I think it must have been legacy. Spilling over and reducing your record id pool? Its pushing the issue down the road but Salesforce does re-use id’s so with potential record archiving maybe in the future (now we have Wave) maybe worth it?
Radnip
January 26, 2015 at 9:26 pm
Asked 🙂
Steven Tamm
January 26, 2015 at 10:25 pm
The documentation you point to is incorrect. We’re updating it.nnCharacters 5 & 6 were reserved as ‘0’ from the beginning. A few years ago we started using the 5th character to represent originating instances. For example, instance cs33 uses “35” as the serverId for the ids it generates, and na41 uses “27”. As data can move between instances pretty easily, the InstanceId is only helpful in determining where a record was generated, not where it is now.nn-Steven
Daniel Ballinger
January 27, 2015 at 12:53 am
Should that be the 4th and 5th characters so it occurs immediately after the key prefix?
Radnip
January 27, 2015 at 10:28 am
He’s saying that 5th & 6th chars have never been used anyway (reserved as ‘0’). So the 4th & 5th can be used as the pod ref and still have an unused 5th char so they still have extra capacity in the id for whatever they need it for in the future…
russforce
January 27, 2015 at 4:33 pm
So looks like per Steven Tamm there are actually 62^3 combinations or 238,328! That’s a lot of servers! Thanks for the technical architecture sleuthing, Francis. This is fascinating inside stuff!
Daniel Ballinger
January 27, 2015 at 6:50 pm
Ah, I think I’ve got it. I didn’t realise there were so may reserved characters. So it is:n* Characters 1, 2, 3 – key prefixn* 4th Character – instance/pod identifiern* 5th Character – instance/pod identifier – extendedn* 6th Character – reservedn* Remaining 9 characters. Record number
Radnip
January 27, 2015 at 10:12 pm
yup thats it 🙂
Radnip
January 27, 2015 at 10:12 pm
So should be enough for a couple of years 😉
keylabs keyabs
April 27, 2016 at 8:03 am
very nice post, its most worthful </a