One of the major new features released with Sitecore 9 was the new API layer for xDB known as Sitecore xConnect. xConnect introduces a variety of new services that can be scaled out to provide a higher-performant architecture for interacting with xDB.
xConnect consists of the following components:
Along with xConnect are a variety of XP services which together with xConnect make up what we call the Experience Platform Foundation (XPF). These include:
Almost all of these services can be scaled horizontally, but it should be noted that the xConnect Search Indexer currently only supports a single instance running at a time, and if you do scale out the Reporting service they must all use a single shared reporting database.UPDATE (2019-10-07): The previous caveats were updated to be more accurate about the scaling of the Reporting instance. It is the database which cannot be horizontally scaled, which is the performance bottleneck usually. The service instance itself can be scaled out horizontally.
Another big announcement which affects scaling is the support for the collection database on SQL Server. This means that all standard vertical and horizontal scaling capabilities for SQL Server can now be leveraged for your xDB data store.
You can also choose to combine some roles together to simplify your architecture. For example, here is a diagram where the xConnect roles have been combined on a single server, with the rest of the services deployed on another. You can dive into the documentation (linked at the end) to learn more about combining roles.
I’ve put together a quick video to visually explain some of the scaling options available with the XP Services (6:07).
You can also hear from Product Manager Todd Mitchell himself explaining the different roles available in XPF:
Learn more about the Experience Platform architecture in the Scaling and Architecture guide:
Wondering, while choosing for collection database between Mongo and SQL, do we have any criteria defined in terms of Traffic/Load etc?
Thanks for the comment Amitabh,
As of right now (9.0 Initial Release) only SQL Server is available for the collection database. MongoDB support will be coming in the future.
I would usually recommend when choosing between the technologies to think about the cost of operations within your team first. Do you have a team that knows SQL? Do you have a team that knows Mongo? How much will it take to learn and become an expert at managing it? Usually, this cost outweighs the minor differences in the technologies.
That being said, even teams that are familiar with SQL Server in a classic sense may not be familiar with the Shard Management used for the collection database, so this needs to be evaluated as well.