Architecture, Development, General

Has Salesforce hit an architectural limit?

And it all started from a Tweet this morning:

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 🙂

Load More Related Articles
Load More By Francis Pindar
Load More In Architecture
  • Daniel Ballinger

    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

  • Pingback: What will happen with the Salesforce Pod identifier when there are more than 62 instances? | DL-UAT()

  • Mary Pustejovsky

    Interesting. I imagine if you asked Stephen Tamm he would be willing to discuss.

  • Radnip

    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

    Asked 🙂

  • Steven Tamm

    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

    Should that be the 4th and 5th characters so it occurs immediately after the key prefix?

  • Radnip

    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…

  • 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

    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

    yup thats it 🙂

  • Radnip

    So should be enough for a couple of years 😉

  • keylabs keyabs

    very nice post, its most worthful </a

Check Also

Time for a tech implant?

A couple of weeks ago I was at ...

Subscribe via Email

Enter your email address to subscribe and receive notifications of new posts by email.

Upcoming Events

  1. Salesforce Automation Hour with Francis Pindar MVP

    2 June @ 8:00 pm - 9:00 pm
  2. Dreamforce 2017

    6 November - 9 November

Follow me on Twitter

Currently reading

From Goodreads

  • Book cover

    The Hitch Hiker's Guide to the Galaxy: A Trilogy in Five Parts

    Douglas Adams

  • Book cover

    The Warren Buffett Way: Investment Strategies of the World's Greatest Investor

    Robert G. Hagstrom