Store architecture diagrams represent the fundamental structure of a particular project, providing a unified vision for 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, which are generally used as a reference for both technical and business teams. Additionally, store architectures define the roles and responsibilities among all stakeholders and explain how different systems interoperate and how data is transmitted between them.

To demonstrate how VTEX integrates with the ecosystem, we've created 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:

• Business-to-customer (B2C)
• Business-to-business (B2B) with B2B Suite
• Franchise accounts (omnichannel)
• Multi-language and multi-currency
  • Single account, multi-binding
  • Multi-account
    • Multi-account, shared back-office
    • Multi-account, independent back-office

Except for the Headless architecture, the following diagrams consider Store Framework as the 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, indicating information exchange between the 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 will 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. Additionally, 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 Order Management System (OMS) and Catalog, 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 surcharge 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 online stores 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 does its own order management.
• Prices and payments: Each franchise can have its own pricing and payment methods, or it can inherit them 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 it 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 each local store to run 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 highlights its main characteristics:

• Separate website: A single 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) across 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. However, 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 go through the Messages API.

In a multi-account architecture, a brand operates multiple VTEX accounts, typically one per country or market, so that each can be localized and managed independently. This architecture is recommended for businesses operating in multiple countries that need to configure different languages and currencies, with different teams managing each localized store.

There are two architectural variants, depending on how back-office systems like ERP, PIM, and WMS are integrated:

• Shared back-office systems
• Independent back-office systems

Why choose this architecture?

• Supports both single-fulfillment (all items shipped from one account) and multi-fulfillment (items shipped from different accounts within the same purchase), optimizing logistics based on item availability and proximity to the customer.
• Facilitates multi-language and multi-currency operations by designating the seller (main account) as the catalog owner and using the accounts for each country as marketplaces, allowing each store to manage its language and currency locally within its own environment.
• Supports independent catalog translations, eliminating the need to rely on Messages or the Catalog translation app, unlike the single account, multi-binding model.

Multi-account, shared back-office systems

In this model, 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. Customer information isn't 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, creating promotions for a customer cluster in the main account doesn't work because the account doesn't have access to Master Data of the marketplace. Additionally, promotions configured in the marketplace based on a seller's payment methods don't work. Learn more in Configuring promotions for marketplaces.
• 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.
• Localization: The catalog can be translated in the marketplace after the seller sends the item.

Assembly options and services aren't supported. Attachments only work if configured in the seller account.

Multi-account, independent back-office systems

In this model, each country or region operates with its own back-office, resulting in greater operational and integration autonomy.

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 account. Customer information isn't shared between accounts, as each has its own Master Data.
• Promotions: Different promotions can be configured for each store. If any individual account runs a marketplace with external sellers, the seller-marketplace limitations are applied within that specific relationship, but that is separate from the cross-country independence model. Learn more about these restrictions in Configuring promotions for marketplaces.
• Checkout, Order Management System (OMS), Payments, and Message Center: Each store manages these modules independently in its own Admin.
• Catalog, Pricing, and Logistics: Each store manages these VTEX core services independently. Integrations aren't shared between accounts.

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, such as pricing, infrastructure, security, checkout. This architecture allows stores to fully control the user experience on the storefront while customizing the 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 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 of 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