What is Composable Commerce?

Composable commerce is all about building your ideal system by combining best-in-class services for each specific business need. Rather than relying on a single platform to handle everything, you select specialized tools - such as a CMS, product database, checkout system - and connect them through APIs.

The key principles behind composable commerce include:

- Best-of-breed approach: Selecting the optimal services for each specific function instead of using a single all-in-one platform

- API-first connectivity: Connecting everything through APIs and utilizing headless frontends for maximum flexibility

- Business agility: Innovating faster, scaling easily, and avoiding vendor lock-in

Simply put, composable commerce enables businesses to move faster, experiment with new ideas more easily, and remain adaptable to whatever the market demands.

How Optimizely Enables Composable Commerce

Optimizely plays a crucial role in building robust composable commerce solutions. Through its SaaS CMS, Optimizely Graph, and other services, it provides powerful tools for managing content, products, and transactional data in a flexible, scalable way. Let's explore two different architectural approaches to implementing composable commerce with Optimizely. These examples differ primarily in whether the Optimizely Connect Platform is used as an integration hub, each with its own advantages and trade-offs.

Traditional Composable Commerce (Without Optimizely Connect Platform)

This architecture represents a more traditional approach to composable commerce, where Optimizely SaaS CMS, Optimizely Graph, and transactional commerce services are integrated directly without a central integration hub. In this model, the headless application acts as the orchestrator that combines all services.

Product Information Management (PIM)

The PIM system enriches product data beyond what's typically supported by SaaS commerce providers, handling both core product data and extended attributes stored as metafields,for example including:

• Subscription Flag: Determines if a product is eligible for subscription
• Default Variant SKU: Defines which variant should be preselected
• Group-Based Pricing: Stored as a JSON object for dynamic price rendering based on user groups
• Product Status: JSON field for availability (e.g., backorder, out of stock)
• Order Limits: Restrictions on how many items a customer can order within a specific timeframe

All this enriched data is sent to the transactional commerce system and consumed by the frontend application.

Transactional Commerce Services

This layer manages all commerce operations including:

• Order Processing & Checkout
• Inventory and Pricing
• Customer Account Data
• Payment Gateway Configuration
• Promotions & Discount Logic
• Marketing Automation (e.g., abandoned carts)
• Category Management and Filtering

It exposes APIs that allow the headless frontend to interact with real-time data for carts, customer orders, and stock availability.

Optimizely Graph

Optimizely Graph functions as a high-performance GraphQL content delivery platform, acting as a CDN-distributed index for all CMS content and localized product information (titles, descriptions, media, etc.).

It delivers:

• CMS Pages and Product Content Blocks
• Localized translations
• SEO metadata
• Product descriptions and assets tied to SKU/product IDs

All this data is accessible by the frontend using GraphQL, enabling dynamic and multilingual rendering.

Optimizely SaaS CMS

This is the content management service used by marketers and editors. It includes:

• A Visual Builder for assembling reusable content components
• Content publishing workflows
• Management of content blocks, pages, and translations

All published content is indexed in Optimizely Graph for frontend consumption.

Headless Application

The headless frontend (built in a framework like Next.js) orchestrates data across services:

• Retrieves CMS pages and product content from Optimizely Graph
• Fetches inventory, pricing, and promotion details from transactional commerce APIs
• Manages cart and checkout flows using commerce services
• Renders localized product detail pages by combining data from both CMS and transactional commerce systems

Product Page Rendering:

• Request commerce service for product data (SKU, price, inventory, status)
• Use the SKU or product ID to query Optimizely Graph for multilingual CMS content (title, description, media)

Cart Rendering:

• Dynamically loads product title, image, and description from Optimizely Graph using SKU or variant ID

Category Pages:

• Retrieved from commerce backend, then enriched with CMS data (if available)

Integration Logic

- PIM → Transactional Commerce: Sends core product data + metafields

- SaaS CMS → Optimizely Graph: Publishes content to the GraphQL index

- Frontend → Optimizely Graph: Loads CMS pages and multilingual product info

- Frontend → Commerce Services: Fetches real-time data like cart contents, prices, promotions, and inventory

You can see an example implementation of this approach using Optimizely SaaS CMS with Shopify HERE.

Composable Commerce with Optimizely Connect Platform

Now let's explore how the architecture changes when we leverage the Optimizely Connect Platform as a central integration hub.

What is the Optimizely Connect Platform (OCP)?

The Optimizely Connect Platform (OCP) empowers developers to streamline data ingestion and channel activation by creating connectors that integrate seamlessly with any marketing suite. Developers can publish these connectors to the App Directory, and marketers can easily install and use them to compose digital experiences. - https://world.optimizely.com/products/ocp/overview/

In essence, OCP allows you to create applications that take information from transactional commerce services and add it to Optimizely Graph. It serves as a hub that aggregates data from multiple sources into one cohesive system.

Let's move on to architecture where we will learn about the strength of the Optimizely Connect Platform

This architecture leverages Application in Optimizely Connect Platform as a central integration hub between content and commerce systems.

PIM (Product Information Management)

The PIM system handles the same product data enrichment as in the previous architecture, managing attributes like subscription flags, default variant SKUs, group-based pricing, product status, and order limits.

Transactional Commerce Services

This layer handles all core commerce operations, including order processing, inventory management, checkout and payment gateways, customer data, marketing campaigns, and product categorization, filtering, and promotion logic.

Optimizely Connect Platform (Integration Hub) Application in The Optimizely Connect Platform acts as an integration layer between commerce and content systems. It:

• Listens to webhooks from the commerce layer (e.g., product updates)
• Synchronizes product and content data into Optimizely Graph
• Updates the content stored in Optimizely SaaS CMS

This makes it easy to keep the product catalog and content in sync without manual intervention.

Optimizely Graph Serves as the central source of truth for the frontend, containing:

• Product data
• CMS content
• Searchable indexes

The headless frontend communicates with this API to render all pages dynamically and efficiently.

Optimizely SaaS CMS

Allows content authors to create and manage content using the Visual Builder. Published content is automatically indexed in Optimizely Graph, making it available to the frontend without delay.

Headless Application (Frontend)

The frontend is fully headless and consumes all data via APIs. It:

• Takes product information from only one place - Optimizely Graph
• Fetches CMS, product, and category pages from Optimizely Graph
• Handles cart, checkout, and order history by communicating with the commerce layer
• Uses identifiers like productId, variantId, and SKU to render product data

Data Flow Summary

- PIM → Commerce: Product data and metafields are synced

- Commerce → Connect: Webhooks notify changes

- Connect → Graph & CMS: Data is synced into Optimizely

- CMS → Graph: Content is indexed

- Frontend → Graph: Frontend fetches all content and product data via GraphQL

- Frontend ↔ Commerce: Handles user interactions like checkout, login and cart

Comparison: With OCP vs. Without OCP

Pros of the Hub-based Architecture:

- Central source of truth – all data is stored in the Optimizely Graph

- Simplified frontend – all product and CMS data comes from Optimizely Graph

- Better control over content and data ownership across teams

- More scalable due to optimized data serving from Graph/CDN

- Easier to manage localization and content enrichment

Cons of the Hub-based Architecture:

- Slower cache revalidation – changes need to pass through multiple systems before appearing in the frontend - Data freshness challenges – frontend content may be affected by delays in webhook chains

Transactional Commerce Services

Both architectures support a wide range of modern SaaS commerce platforms, such as:

• Shopify
• BigCommerce
• commercetools
• Commerce Layer
• Salesforce Commerce Cloud
• And many others

While the core functionality of these platforms is similar, there are subtle differences in data models and APIs. For example:

• Shopify does not expose a product SKU directly. Instead, SKUs exist only at the variant level.
• BigCommerce, on the other hand, supports both product-level SKUs and variant SKUs.

Different commerce platforms may have varying data models, but the overall architecture remains consistent regardless of the specific platform chosen.

Real-World Example: Custom Composable Commerce Architecture

Let me share a more complex real-world implementation that we at Hatimeria developed for a client. This architecture demonstrates how composable commerce can be customized to meet specific business needs:

The following example illustrates: -PIM (Pimcore): Stores enriched product data in BigCommerce metafields — availability, variants, pricing per user group, inventory, status, subscription flag, loyalty points, alternatives, etc.

• SaaS CMS: Single source of truth for product content (title, images, description), CMS pages, blocks, and transactional content. Product content linked via SKU.

• BigCommerce: Core commerce engine — customer data, cart logic, checkout setup, payment, and reporting. Stores product base info and PIM metafields.

• Checkout (BigCommerce SDK + Azure Functions): Custom checkout UI. Promo codes and final calculations are processed via Azure Functions, not native BigCommerce.

• Promotions (.NET Engine): Custom UI for managing promotions - define conditions (customer, product, time-based), rewards (discounts, gifts, points). Stored in a database.

• Azure Functions: Handle advanced cart logic — fetch data from BigCommerce, CMS, and customer service, validate products, apply promotions, and update cart metafields.

• Algolia: Fast search and category results. Index updated hourly and via real-time webhooks from CMS and BigCommerce.

• Headless App (Next.js): Orchestrates frontend — content from CMS, products merged via SKU from BigCommerce + CMS, search from Algolia, cart/promo logic via Azure. Checkout handled on separate domain via BigCommerce SDK.

Data Flow Highlights:

• PIM ➜ BigCommerce (metafields)

• CMS ➜ Headless App (content, product info)

• BigCommerce ➜ Headless App (products, cart)

• Headless App ➜ Azure Functions (cart calculation & validation)

• Azure Functions ➜ BigCommerce (cart metafield updates)

• Webhooks (BigCommerce/CMS) ➜ Headless App ➜ Algolia (real-time reindex)

This modular setup ensures agility, enables deep customization at every stage of the customer journey, and supports a real-time, high-performance commerce experience. Implementing such an architecture wasn’t easy - it required significant effort and deep technical alignment across services. But to stay ahead of the competition and meet ambitious business requirements, such as fully custom promotion logic that no out-of-the-box platform could support, this level of complexity was essential. After all, this shouldn’t be simple - this is business critic

Key Takeaways

• Without Optimizely Connect Platform: Offers greater flexibility and real-time access to data but can be more complex and harder to manage, especially when dealing with multiple APIs.

• With Optimizely Connect Platform: Simplifies integration, centralizes data management, and enhances scalability, though there may be some delay in data synchronization.

Both approaches are powerful, and the choice depends on the specific needs of your business and the complexity of the system you’re building.

Final Thoughts

The architectures discussed demonstrate the power and flexibility of building composable commerce solutions with Optimizely. By separating concerns between Product Information Management, Transactional Commerce Services, Optimizely Graph, and a Headless Application, we can create highly scalable, customizable, and performant ecosystems tailored exactly to business needs.

While the diagrams presented here are conceptual and simplified for clarity, in real-world scenarios many more factors must be considered, including authentication, caching, synchronization challenges, failover strategies, and others. However, the core beauty of composable architecture remains clear: it allows us to easily integrate new services, extend features from different providers, and orchestrate everything within a single, unified headless application.

The Optimizely Connect Platform can be an incredibly powerful tool in this landscape, offering a modern way to stitch together content, commerce, and search across distributed systems with great performance and flexibility. Combining multiple systems is never trivial - it requires deep technical expertise, a strong architectural vision, and the ability to navigate integration challenges. But when executed properly, it unlocks tremendous value and creates best-in-class digital experiences.

Explore More

If you'd like to see composable commerce with Optimizely in action, check out these resources:

• Composable Commerce with Feature Experimentation - See how feature flags can help you test different commerce services (Shopify vs BigCommerce)
• Optimizely SaaS CMS with Shopify - A working example of the first architecture
• Headless using Optimizely SaaS CMS course - Learn how to get started
• Content-rich website using Optimizely SaaS CMS - See a simple implementation

This article was originally published on Optimizely.com.

Ready to build a high-performance composable commerce solution with Optimizely? Partner with Hatimeria and turn your architecture into a competitive advantage. Get in touch today - let’s compose the future of commerce, together.