Store architecture diagrams represent the fundamental structure of a particular project, providing a unified vision to all stakeholders and translating business needs into software components and project requirements. In this guide, we present an overview of basic store architecture models on VTEX.

There are different types and levels of architecture, but they generally work as a reference for technical and business teams. Additionally, store architectures define the roles and responsibilities of each player for all stakeholders while explaining how different systems interoperate and how data is transmitted between them.

To demonstrate how VTEX integrates with the ecosystem, we have created VTEX reference architecture models based on common digital commerce strategies. These blueprints illustrate interactions between VTEX modules and the business, serving as a starting point for projects. Learn more about the structure of these models in Understanding VTEX reference architectures.

These are the main use cases for common scenarios:

• Business-to-customer (B2C)
• Business-to-business (B2B)
• Franchise accounts (Omnichannel)
• Multi-language and multi-currency
  • Single account, multi-bindings
  • Multi-account

Except for the Headless architecture, the following diagrams consider the client is using Store Framework as a storefront solution.

Business-to-customer (B2C) is the most common business model among VTEX clients and serves as a foundation for other models.

The diagram below illustrates the main components of a B2C commerce implementation. Components highlighted in pink are offered out-of-the-box (OOTB) by VTEX. However, the diagram also includes other parts that may be integrated from the client's internal back-office systems or third-party providers.

Below is an integration flow diagram in a B2C architecture, where asynchronous calls (not in real time) are represented by black arrows, and synchronous calls (in real time) are represented by blue arrows.

An example of an asynchronous call is the stock update, represented by a black arrow pointing from the ERP to the Inventory module. A real-time update of payment rates is represented by a blue arrow, with information exchanged between both blocks. This last scenario is synchronous because it occurs in a critical stage of the customer purchase flow.

The architecture suggested here extends beyond B2C, as you can see in the following sections.

The main characteristic of a business-to-business (B2B) model is that transactions occur between two or more legal entities.

The diagram below presents an example of a B2B business model using B2B Suite, represented within the B2B Core Modules. In this architecture, the main account acts as a marketplace for other VTEX sellers.

B2B Suite is a set of VTEX IO apps tailored to streamline B2B store management. This collection of apps enables the store to manage organizations (the companies enabled to make purchases in the store) and other functions and permissions for storefront and checkout. For instance, the store can offer specific price tables, collections, and custom payment methods for organizations. Besides, clients can have different user roles within organizations, among other features.

The main account has access to more modules than the sellers, sharing only some of them, such as the Order Management System (OMS) and Catalog modules, as you can see in the diagram below.

Declaring these modules in the architecture not only makes the process clearer but also makes it easier to understand the responsibilities of each player. In this case, for example, Master Data remains with the sellers because customer approvals are handled at the seller level.

In B2B scenarios, real-time communication between the B2B Suite and sellers is common, as the information is always up-to-date. This is also crucial for fee and tax calculations at checkout to ensure a smooth purchasing experience for the end customer.

In the diagram above, you can see the synchronous communication between the Organizations component in the main account and the sellers.

• Streamlined organization management: Manage multiple organizations from a centralized platform by grouping storefront users into organizations and dividing them into cost centers.
• Customized user experience: Tailor the user experience for each organization, providing personalized pricing, payment methods, and product catalogs to meet specific business needs.
• Enhanced security and control: Assign roles and permissions to B2B clients, ensuring appropriate access levels and maintaining control over sensitive information and transactions. Learn more in the Storefront Permissions and Storefront Permissions UI app documentation.
• Optimized quoting system: Facilitate quote requests and management, enhancing negotiations and ensuring accurate pricing by integrating the quote-to-order process.
• Efficient order processing: Simplify the checkout process with shared shipping addresses for cost centers, reducing errors and streamlining order fulfillment.

• B2B Suite - Overview

This is a very common architecture model that integrates physical stores with ecommerce as franchise accounts on VTEX.

A franchise account is linked to a main account and has the following characteristics:

• No separate website: Franchise accounts have no dedicated website. Instead, they operate within the main account's ecommerce site as part of a larger marketplace.
• Customer data storage: Customer data is stored in the main account's Master Data.
• Seller type: Each franchise account automatically operates as a white-label seller within the main account.
• Catalog: Franchise accounts inherit their catalog from the main account.
• Logistics and OMS: Each franchise account has its own logistics settings and performs its own order management.
• Prices and payments: Each franchise can have its own pricing and payment methods, or they can inherit these from the main account.
• Promotions: Promotions can be created for each franchise account and for the main account.

This architecture model works well for brands with multiple physical stores, franchises, or representatives. In these cases, each physical store/franchise/representative can have a franchise account on VTEX integrated with the brand's main account. This allows them to deliver the products sold through the brand's ecommerce site from an omnichannel perspective.

• Potential to reduce the percentage of out-of-stock items.
• More shipping options, potentially reducing logistics costs.
• Physical stores can be configured as pickup points.
• Physical stores can operate as small warehouses, using the ship-from-store strategy.
• Possible inventory reduction through the implementation of the Endless Aisle strategy through VTEX Sales App.

VTEX Sales App is available in Brazil and some LATAM countries. To check if it's available in your country, open a ticket with VTEX Support.

Some of our clients operate in multiple countries and want to have each local store running on VTEX. We provide a multi-language and multi-currency architecture for this scenario, which is explained in the following sections.

In this architecture, a single VTEX account is configured to support multiple languages and currencies using a multi-domain approach.

The reference architecture below exemplifies its main characteristics:

• Separate website: A si-gle account, but each store with its own domain, bound to different trade policies by bindings.
• Search: Same search settings for all websites.
• CMS: Shared access to the Content Management System (CMS) between websites.
• Customer data storage: A single Master Data for all stores.
• Catalog: A single catalog segmented by trade policies.
• Logistics: Each store manages its logistics through different warehouses in the same logistics panel.
• Order Management System (OMS): A unified OMS panel for all stores.
• Payments: Shared payment settings across all stores.
• Prices and promotions: Different prices and promotions can be configured for each store, segmented by trade policy. Still, prices and promotions for all stores are managed in the same panel.
• Message Center: A single Message Center for all stores.

This model is easier to set up, integrate, and maintain compared to the multi-account approach, but it may not be efficient for large and complex operations. This architecture is recommended for operations across multiple countries that require configuring different languages and currencies but don't require data segregation, as all core services are shared. Therefore, it may work well for operations managed by a single, centralized team.

Why choose this architecture?

• Supports multi-currency natively.
• Supports multi-language with Messages and the Catalog translation app.

Product names aren't translated on the Checkout and My Account pages. These modules call the Catalog API directly to retrieve product data, so the information doesn't pass through the Messages API.

In this architecture, a main account acts as a seller in secondary accounts that act as marketplaces.

The reference architecture below highlights its main characteristics:

• Separate VTEX account: Each store operates with its own VTEX account.
• Separate website: Each store has its own website and can customize a different frontend style.
• Customer data storage: Customer data is segregated by marketplace account. No customer information is stored within the main account's Master Data.
• Promotions: Promotions from the main account have limited capabilities because the main account can't access customer data from the marketplace. For example, if you want to create promotions for a customer cluster in the main account, it won't work because the account doesn't have access to the marketplace Master Data.
• Checkout, Order Management System (OMS), Payments, and Message Center: Each store manages these modules independently in its own Admin, without relying on the main account.
• Catalog, Pricing, and Logistics: The main account is the source of truth for these VTEX Core services, but management is independent, as each account has its own Admin. The product assortment can vary between accounts, but it's always based on the main account's catalog, as the main account is the owner.

Assembly options, attachments, and services aren't supported.

This architecture is recommended for operations across multiple countries that require configuring different languages and currencies, where different teams manage each localized store.

Why choose this architecture?

• Supports both single fulfillment (all items shipped from one account) and multiple fulfillment (items shipped from different accounts within the same purchase), ensuring efficiency by optimizing logistics based on item availability and proximity to the customer.
• Having the seller (main account) act as catalog owner and the accounts for each country act as marketplaces enables a multi-language solution. This allows each store to manage its language and currency locally within its own environment.
• Support better translations compared to the single account, multi-binding model, as there is an independent catalog translation. Therefore, you don’t need to rely on Messages or the Catalog translation app.

Learn more

• Accounts and architecture
• Choosing between a multi-store architecture or an additional environment

In a headless architecture, the frontend (or "head") is decoupled from the backend. This allows the user interface to be built with any technology while the backend supplies the data and functionality, providing greater flexibility and scalability.

The frontend layer includes font type, colors, styles, images, buttons, etc. The backend manages the ecommerce functionality, pricing, infrastructure, security, checkout, and more. This architecture allows stores to fully control the user experience on the storefront while customizing backend to meet their specific needs.

The diagram above represents an account implemented with FastStore, the VTEX native solution that allows developers to build headless storefronts. It outlines the main components of a headless implementation, providing an overview that can be expanded to address specific business needs.

If your store uses a third-party Content Management System (CMS) instead of VTEX storefront solutions, you can leverage VTEX APIs to build a headless shopping experience. Learn more in the Headless Commerce guide and the Pragmatic Composability section in the Composability guide.

• Flexibility: A headless approach allows complete ownership over the website architecture.
• Faster websites: A headless ecommerce platform houses content centrally and can deliver it anywhere via APIs, allowing faster delivery compared to traditional ecommerce architecture.
• Personalized experiences: Stores can create customizable experiences and adapt them to achieve the desired look and feel.
• Low-risk experimentation: Decoupling the backend from the frontend makes it simpler and less risky to make changes to the frontend, knowing that it won't impact the site's underlying backend architecture.
• Seamless integration: Stores can integrate their existing systems (ERP, PIM, OMS, etc.) to build a cohesive shopping experience using any programming language.

• Headless CMS - Overview