Skip to main content

Architecture overview


Overview of the three major Sitecore Experience architectural elements: Manager (XM), Platform (XP) and Commerce (XC).

Sitecore consists of three major products:

  • Sitecore Experience Manager (XM)

  • Sitecore Experience Platform (XP)

  • Sitecore Experience Commerce (XC)

Each of the Sitecore components contains a number of logical entities that together with a number of cloud services form the entire functionality of the Sitecore platform.


The roles depicted here are logical and do not represent physical or virtual servers, database servers, or search engines. Some logical roles can be combined into single physical entities within a topology.

XM refers to the web content management (WCM) core of XP. XM encompasses the features involved in the creation, management, personalization, and publishing of content. It consists of the subset of the logical roles:

XM - arch overview - 9.0

See also:

XP combines XM with the marketing and customer intelligence features offered by xConnect and xDB, which introduce a number of additional server roles and storage mechanisms.

  • xConnect is the name given to the set of services that sit in between xDB and any trusted client, device, or interface that wants to collect and search experience data over HTTPS.

  • xDB is the name given to the collection of services and storage roles that store and process experience data. Clients that are external to xDB - such as a Content Management server - must use xConnect to read and write xDB data.

The following diagram lists the logical roles that are added by XP:

XP - arch overview - 9.0

XP roles extend the content management, personalization, and delivery features of XM with features that enable cross channel experiences, customer and business insights, collect actionable customer information and provide context when shaping the experience for customers.

The following diagram lists every logical role included in XP:

XM+XP - arch overview - 9.0

See also:

XC - arch overview - 9.0

See also:

Single and multitenancy

XC is configured for both single and multitenancy out of the box.

XC - single tenancy - 9.0+

With a single tenancy setup, you have a single website – or storefront – served by the Content Delivery role.

This storefront makes calls to the commerce engine, accessing the entities and business logic configured for it.

XC - multi tenancy - 9.0+

With a multitenancy setup, a Content Delivery role can house multiple storefronts and your engine can host multiple entity and business logic configurations.

In other words, you can have a single Content Delivery and commerce engine, hosting numerous sites each with completely tailored functionality not only in the user interface but also in the commerce engine.

Policies, environments and storage roles

There are two storage roles – or databases – in XC:

  • The Global database – stores all the global configuration data (policies and environments) that govern how the engine roles function.

  • The Shared Environments database – the main data store for a commerce deployment. It stores all of the commerce data used on site, including catalog data, customer records, pricing information, and any promotions you have configured, along with the generic entities and lists that power the functionality created in the various installed plugins.

A policy is a group of settings that define and affect the functionality of the individual features or plugins in the commerce engine.

Policies are named, versionable, variable datasets that help make the engine flexible and configurable. They are stored in the policy store in the Global database and are heavily cached.

An environment in XC is a collection of policies that affect how a call to the engine is handled. In other words, when a storefront calls the commerce engine for any functionality, it identifies the appropriate environment, which in turn effects the functionality provided by the engine.

Environments provide you with the ability to have separate functionality hosted in a single service instance.

This means that you can have the same call to the engine function very differently, depending on which environment variable is passed in. For example, if you request product details using a publicly facing Shops Environment, it would probably read from a cache to improve performance, whereas using a management facing Authoring environment would most likely pull data directly from the database.

Typically, you change policies and environments as part of a deployment using a process called bootstrapping.


Bootstrapping is the process of loading a set of changed configurations into the commerce system, changing the data models or functionality.

You create and manage environments and policies in configuration files – specifically JSON files – as part of the development or DevOps process.

XC - bootstrap by JSON - 9.0+

To reconfigure and bootstrap XC, a developer or system administrator first stops all the engine roles that depend on the new configuration, then deploys the changed JSON configuration files to the DevOps role and subsequently uses a REST API tool, such as Postman, and triggers the Bootstrap REST call on the DevOps role. You can also execute the bootstrapping as part of a continuous deployment through a PowerShell script or similar.

The JSON configuration is read from the files on disk and the environment and policy data is stored in the Global database. If the bootstrapping is successful, the system runs with the new configuration and a message is returned to the developer or system administrator. When the engine roles are started again, they read the new configuration from the Global database.

XC - bootstrap by DevOps - 9.0+

You can also use the DevOps role to trigger other maintenance and deployment tasks, such as a rebuild of indexes in the system. Just as with the bootstrapping command, this can happen through a manual REST call or through a script. Reindexing loads data from the Shared Environments database and repopulates the appropriate index.