Have you ever noticed that Infusionsoft ID numbers behave a little strangely? Sometimes they are odd, and sometimes they are even. They almost always skip numbers. Why does this happen, and does it matter?
Why does this happen?
Infusionsoft uses multiple SQL databases to run your app. This is a standard practice that allows your app to keep working even if one of the SQL databases fails or needs to be taken offline for updates. The databases share any updates with each other so both hold a full copy of all your data.
For example, you create a new contact. Infusionsoft creates the contact in database A. Database A shares the new contact with database B. Now both databases have the contact, but there is a short period of time between updates when the two servers may be slightly out of sync. For a short moment, database B doesn’t know anything about the new contact.
To keep from accidentally using the same ID number for two records, each database follows its own numbering scheme. For example, database A only uses odd numbers, and database B only uses even numbers. While Infusionsoft is adding contacts to database A, all of your new contacts will have odd ID numbers. If it switches to database B, then you’ll start to get even ID numbers for your contacts.
Does it matter?
This probably isn’t a big issue for most people, but it can be helpful to be aware of some possible side effects of this numbering scheme.
The first side effect is that the highest ID number doesn’t reflect the number of records in your app. In the above image you can see that my example app has 3092 contacts but the highest ID number is 7073. The ID number can’t be used to determine how many records have been created.
Another side effect is that ID numbers can be out of order. This happens very infrequently, but it is possible for ID numbers to be created in a non-sequential sequence, such as: 302, 304, 303, 305. Notice that 303 was created after 304. This means that the ID number can’t be used to determine the order that records were created in your app. Use the date created field instead.