Guide to building a perfect composable ecommerce solution architecture

The essence of a composable ecommerce business resides in its agile approach and ability to implement online commerce business processes in a modular architecture, selecting and applying the best components available on the market and seamlessly integrating them into an ecommerce platform.   

Virto Commerce B2B marketplace platform provides flexible and modular free-to-choice business scenarios that a retailer would like to make available to customers. The API-based applications collect data from the ecommerce back end, then deliver product and price data over the network to a broad array of digital touchpoint front ends and return a purchase order vice versa, to the back end. 

If you are a retailer and your IT team starts adapting the system architecture for composable commerce, the process seems to be very long and unclear. Do not worry; Virto Commerce offers a guide that allows you to start building composable architecture on our B2B platforms in just a few steps.

Let's take a look at the 5-level composable architecture diagram (Fig.1):

1. In the header are services we want to run within the ecommerce platform (accounts, prices, catalog, etc.).

2. The application matrix is divided into two zones: Real-time applications (levels #3, 4, 5) and non-real-time applications (levels #1, 2). There is an integration bus between them to transfer data. You need to fill in all cells marked “Select product”.

3. Direct or point-to-point communication between two zones (real-time and non-real-time one) is not allowed.

4. The non-real-time zone defines back-office applications that can run the required service. One application can run several services; it can be an existing application or a new application from Virto Commerce or a third-party vendor.

5. The real-time zone could contain cloud services, API, business logic and real-time applications. These applications meet the following criteria: performance, scalability and zero downtime.

Let us fill in this ‘applications and services 5-level matrix’ in the following example to get the fully functional composable ecommerce platform. 

1) First, define what kind of applications you require to build your dream-like ecommerce platform. For example, you need to have client accounts, authentication, products, prices, order processing, etc. These services must therefore be included in the matrix header. If you have a real-time application providing data from accounts, authentication, products, prices, order processing and other services on your ecommerce platform, just enter the name of this app into the corresponding cell(s). If you have non-real-time services for data of accounts, authentication, products, prices, order processing, etc., you must build a corresponding real-time service(s) for level #3. 

2) Define all currently existing applications that deliver services of affordable quality.

a) For example, you have a well-functioning ERP system to store client accounts, prices and orders.  If these services work OK, enter something like “My ERP” name in the corresponding cells of level #1. If the required service is not available, put a dash or cross in such a cell at level #1 (see Fig.2).  

b) If the current back office is not perfect, you can opt for a replacement application from the Virto Commerce platform or get the best third-party one from the market. Let’s assume you use Virto Commerce products, enter “VC” in the corresponding cells in level #2. Fill in the remaining empty cells with a dash or a cross in level #2 (see Fig.2).

Thus, we have defined the application that provides the master data. 

​​​​3) Next, move to the real-time zone in level #3. If “My ERP” is non-real-time app, you must build or choose a real-time app for the cell of the corresponding column at level #3 that meets the criteria of performance, scalability, zero downtime. Mind that apps on non-real-time levels must not have point-to-point connections with real-time levels. They would only work asynchronously over an integrations layer.

For example, as a counter-side application to the ERP accounts service, let us choose the VC index based on Elastic Search. In Virto Commerce, Elastic Search is used as a built-in search engine. If so, enter this VC Index (Elastic Search) name in the corresponding cell (fig.3). You must then set up the data transfer from My ERP to VC Index through the Integration Layer to import any new client accounts from My ERP asynchronously into the VC Index and back.

For the authentication service, i.e. Authentication column of the matrix, you have chosen the VC Back Office application, and since it is a real-time application, you simply repeat VC in the corresponding cell in layer 3 (Fig.4).

For the Product subset column, add VC Index (Elastic Search) to the corresponding cell in layer #3. Then set the data exchange between VC Index (layer #3) and VC Back Office application responsible for the product subset at layer #2 (Fig.4).

Consider applying the same rules to the Price and Purchase order column – set the data exchange between layers #2 and #3. Mind for orders, the direction of the data transfer would be opposite, i.e. from real-time VC application to My ERP.

4) Layer #4 of API Pipelines defines the business rules (logics) as it works with real-time data from other applications and services in all real-time zones (layers #3 to #5). This is a single place where we store all the platform business logics.

For example, if a corporate client in B2B ecommerce is looking for a product, you have to show personalized products and prices for this account. Accordingly, from the Product Subset, the business logic is established with the VC Index client's accounts (cell at layer #3 for accounts), then for this client, the products allowed for sale (cell at layer #3 for products) and prices (cell at layer #3 for prices). Accordingly, the price of the chosen product is given by the API to this corporate client upward through level #5 to a touchpoint (Fig.5).

What is next? You have a legacy back office application engaged to a new system architecture. eCommerce data can only be accessed there via real-time data source. Event bus and Integration middleware help sync data between real-time and non-real-time applications. Virto Commerce consolidates business logic and provides a unified API for all touchpoints.

Congratulations! You have built a composable ecommerce solution architecture ready to work. You can then plan any improvements, while this guide helps you to keep the system architecture within the composable ecommerce principles.