Sitecore Commerce architecture and design concepts

The Sitecore Commerce solution uses a combination of design concepts and architectural entities to achieve configuration, scalability, and extensibility.


All commerce functionality in the Sitecore Commerce solution is delivered by the Commerce Engine. Configuration of the Commerce Engine is defined through a set of policies.

A Sitecore Commerce policy is a group of settings that affect the functionality of a specific feature in the Commerce Engine. All policies are stored in a centralized policy store. Policies are heavily cached and rarely change their values outside of deployment scenario.

You can change configuration by editing the appropriate policy file.


A Commerce environment is a collection of policies that affect how a call to the Commerce Engine is executed.

Environments allow you to maintain separately configurable pools of data and service functionality hosted in a single service instance. This means that the same call to the Engine can behave differently, depending on what environment variable specified.

Environments can share the same persistent store as other environments or be separated into their own exclusive persistent store.

The Sitecore Commerce solution provides two environments by default: an Authoring environment and a Shops environment. The primary difference in the two environments is the level of caching.

  • Authoring environment: caching is minimal. This means merchandisers or customer service representatives using the Business Tools always see the latest data because the information is retrieved directly from the database (and not cached values).
  • Shops environment: caching is enabled for improved performance. This means that website visitors and shoppers can view product details, for example, more quickly because the data is read from cache (as opposed to retrieving the information directly from the database).

You can also create your own environment and customize the configuration as required.

Bootstrapping is the process of loading the policy and environment data from JSON files on disk created during deployment, into the global policy store so that other Commerce Engine instances can access it. After bootstrapping, the environment JSON files are no longer needed. The Commerce Engine retrieves any subsequent environment configuration directly from the database during normal runtime operations.


The Sitecore Commerce solution implements the concept of Commerce Engine roles to support scalability.

In a production environment, traffic is usually split up among multiple installed instances of the Commerce Engine, which are usually physically located close to their traffic sources. These instances are referred to as Engine Roles. This distinction is purely logical Engine roles are defined by where the traffic they serve originates from.

Service roles can exist on the same or separate servers, and can be scaled independently as required. Each service role represents an instance of the Commerce Engine, and has different load characteristics

Each deployed role can have different policies and behaviors, which can be specified using a specific Commerce environment for that role. When a call is made to the Commerce Engine, the call’s header specifies an environment. This environment is used by the engine to control policies and behavior for that call.

Specifying a particular environment allows explicit independent control (per role) of functions, such as caching, data storage, integration connections, and so on.

The Sitecore Commerce solution defines four Commerce Engine roles:

  • Authoring role

    The Authoring role is the instance of the Commerce Engine that serves traffic from the Business Tools. Since this role serves lighter traffic (because ecommerce solutions have relatively few business users compared to the number of shoppers), scaling requirements are normally relatively low.

  • Shops role

    The Shops role is the instance of the Commerce Engine that serves traffic from one or more storefronts. This role can scale to support demand, and is usually installed in close proximity to the Sitecore XP instances that generate the traffic.

  • Minions role

    The Minions role is an instance of the Commerce Engine that runs independently and supports asynchronous processing (including any post-order capture processing as well as any cleanup. The Minions role is usually set up as a worker role (not a web role) and doesn’t receive any web traffic. This role contains a series of minions, each one with a specific task (for example, a pending order minion that is used to process the pending orders queue).

  • DevOps role

    The DevOps role is an instance of the Commerce Engine that is internal and only available to DevOps personnel. This role can be assigned higher privileges allowing DevOps personnel to perform maintenance tasks that are not permitted to other roles (for example, bootstrapping and environment initialization functions).


The Commerce Engine includes a pluggable framework for extending or modifying existing functionality. The Sitecore Commerce plugin architecture provides extensibility points for custom functionality, without compromising upgradeability.

This plugin architecture allows for opt-in complexity and progressive enhancement of your Sitecore Commerce solution. You can write plugins for connectors to integrate third party systems. You can also write plugins to extend business logic, or to extend the Business Tools.


For Sitecore Commerce, there are two databases: the shared environments database and the global database.

The shared environments database is the main data store. This database stores all of the commerce data used on the site (for example, catalog data, customer records, pricing information, configured promotions), as well as the generic entities and lists that power the functionality of the various installed plugins.

The global database stores all the global configuration data that governs how the engine roles function. The global database stores all of the environment and policy data when you execute the bootstrap function (that is, the configuration stored in the JSON files).