Is there a reason xDb contact data is saved on session end vs immediately saving the data

Question

So from my understanding it's better to use the tracker to update custom facets (or default facets) from a contact in xDb and then wait till SessionEnd to have that data saved to MongoDb. But my question, is why is that the best approach? Is there any performance or locking reasons to why this is the preferred approach, vs the approach of saving this data directly to Mongo before session end using a method like:

ContactManager.SaveAndReleaseContactToXdb(contact);
ContactManager.FlushContactToXdb(contact);

Answer 1

It saves at sessions end because when the contact owner is on the site, the contact is locked in xDB. You couldn't save it if you wanted to. You have to wait until it is saved and the contact is released. This is the major flaw with xDB and the reason xConnect was created.

In 9.0 xConnect resolves this by making the contact separate from the session. You can update and save as much as you want.

Answer 2

Prior to Sitecore 9, the locking was definitely an issue and flushing at session end helped with the locking problem. Locking issues could still occur, but it was less frequent.

As @Chris Auer mentions, changes in 9.0 solved the locking issue, but the content delivery servers are still set up to flush at session end for performance reasons.

While you CAN send data at any time into xConnect, it is still more performant from a networking and processing perspective to batch up all the data you learn and then submit it as a batch to xConnect to process all the operations at once. This keeps your network I/O down, especially now that xConnect can be handling multiple sources of communication (Commerce, DEF, third parties, etc.)

You can definitely trigger calls immediately now, but just like with Marketing Automation live events, you want to be careful how often you do this or else you might need to scale out more instances to handle traffic load of so many concurrent requests.

As with any scaling discussion, think about what would happen with a high volume load and look at the choke points. You can solve it with hardware, but you can also solve by changing how 'real time' your data saving/retrieving is.

In some scenarios, real-time is a necessity, but note that even if you immediately push it into the xDB, it usually won't be available to other systems until the xConnect search indexer puts it into the index. So if you do have real-time needs for some data, don't forget to look at your indexer to make sure it is operating with the configurations and specs you need to keep things up to date in the index.