7

Currently the pod instance that a record is created on is encoded in the 4 character of the ID, immediately after the key prefix. There are some more details about the Pod identifier in the question What are Salesforce ID's composed of?

As per Has Salesforce hit an architectural limit?, there are currently 61 pods listed on trust.salesforce.com.

What happens when the 62 possible values allowed by base-62 encoding is exceeded?

Will it move to the fifth character as well?

Community
  • 1
Daniel Ballinger
  • 102,288
  • 39
  • 270
  • 594
  • Just curious, why are you tracking the pod? – Adrian Larson Jan 26 '15 at 19:40
  • Seems they would just make the "Really big number" part of the id a little smaller (e.g. remove a digit and add it to the pod. I think it would still be large enough to handle more records than you could possibly hold in Salesforce. – Adrian Larson Jan 26 '15 at 19:42
  • @AdrianLarson Mostly out of interest in how the IDs work. In terms of functionality, the only viable use I've found is determining if an OrgID is for a sandbox or not, and then using the correct login URL. Otherwise things like pod migrations make basing any functionality off the pod id too risky. – Daniel Ballinger Jan 26 '15 at 19:46
  • @AdrianLarson Moving to the next character makes more sense than increasing the number of characters in an ID. Increasing the length of an ID would cause wide spread chaos. – Daniel Ballinger Jan 26 '15 at 19:59
  • That's my line of reasoning as well. I'm not in the know though so I'm not sure I should post an answer like that. – Adrian Larson Jan 26 '15 at 20:02
  • Interesting question. I think they would just start grouping pods in groups of 62, and abstract that away. Nothing stopping SFDC from doing that if they wanted to. And that the pod group would not be persisted in the ID. That's what I'd do at least. I'd rather not tinker with the ID any more than needed. – CoryCowgill Jan 26 '15 at 20:12
  • 1
    @daniel Snap :) Was that before or after my blog post. Think we came to the same conclusion :) Couple of options. How dependant is it? Creating a sandbox mixes the id's and server id's up anyway. There is probably a lot of legacy code around for it but to me the reasons of having it may not be around any more. But by increasing it is reducing the pool of record id's so isn't that pushing the issue down the road? But with wave and potentially the ability to archive data in the future it maybe a mute point. – Francis Jan 26 '15 at 21:16
  • @Francis Just after your blog post :) @ca-peterson brought it up in 2012. Agreed, the more people talk about it the less I suspect they would use the next character. Too many potential issues. – Daniel Ballinger Jan 26 '15 at 22:08
  • Oh yes. Well its spilled over now... – Francis Jan 26 '15 at 23:00

1 Answers1

3

And the answer comes from Steven Tamm himself:

"@radnip We've used 2chars for server id for a while now. This documentation is out of date" Source

well that clears that up :)

The documentation you point to is incorrect. We're updating it.

Characters 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.

Steven Tamm
Source

Community
  • 1
Francis
  • 808
  • 6
  • 17