What is composable commerce? Definition, architecture and when it pays off

For a CTO or e-commerce lead, the useful questions are what you assemble, what the glue costs and when a monolith or hybrid platform is the better answer.

Composable commerce definition

Composable commerce is a way of building an online store from independent packaged business capabilities (PBCs), such as cart, search, pricing, and order management, that you select, connect through APIs, and replace one at a time.

A PBC is a self-contained unit that owns one business function, its data, and its API, and is typically built to MACH architecture principles: microservices, API-first, cloud-native SaaS, and headless.

Netguru designs and builds headless, API-first and composable commerce platforms on commercetools, VTEX, Saleor, Medusa, SAP Commerce Cloud and Shopify Plus. We recommend extracting one PBC first, such as search, because it proves the integration pattern before checkout is touched. For teams already evaluating an engine, our commercetools development services cover integration with PIM, CMS and order management systems.

What is MACH architecture and how composable commerce works

Composable commerce works by connecting packaged business capabilities through synchronous APIs for anything the shopper waits on and through events for everything else.

MACH architecture gives each capability its own API and release cycle. A stack might pair a commerce engine such as commercetools or Medusa with a PIM (Pimcore, Akeneo, inRiver), search (Algolia, Elasticsearch), payments (Stripe, Adyen, PayPal) and BNPL (Klarna, Affirm).

A headless frontend and an API orchestration layer, usually a BFF or gateway, combine those services into one response for the storefront.

Choosing which capabilities to buy, build or connect is rarely trivial, which is where commerce architecture consulting can help teams map the right stack before committing to vendors.

The design decision is which calls block the shopper and which do not:

Our recommendation: keep a call synchronous only when the shopper cannot proceed without the answer, or when a wrong answer costs money. Put everything else on the event bus.

Event-driven integration means eventual consistency. Make consumers idempotent, tolerate out-of-order delivery, and let listing pages read cached prices while cart and checkout re-validate against the commerce engine.

Keep the synchronous chain in the orchestration layer short. Set a timeout budget per upstream call and add circuit breakers with a defined fallback, such as hiding recommendations when that service is slow.

This pattern has a limit. With two or three services, webhooks are usually enough and a full event bus adds operating cost. Teams designing the integration layer can start from our API-first commerce services.

What does composable commerce architecture look like?

Composable commerce architecture stacks four layers: a headless frontend, an API orchestration layer, packaged business capabilities, and an event bus that carries state changes between them.

1. Headless frontend: a storefront, app or kiosk that talks only to its own backend-for-frontend.
2. API orchestration layer: one BFF per channel behind an API gateway, handling auth, caching and aggregation.
3. Packaged business capabilities: a commerce engine (commercetools, Saleor, Medusa), product information management, an order management system, search and payments, each owning its data.
4. Event bus: event-driven integration that publishes facts such as product.updated, stock.changed and order.placed.

The layers are easy to draw. Two failure modes appear once traffic arrives, and both can be caught early.

Checkout fan-out

Assume five sequential synchronous calls at 200 ms each and 99.9% availability per service. Checkout then costs one second of backend time before rendering and succeeds about 99.5% of the time (0.999^5). These figures are illustrative assumptions, and the compounding is the point.

Call independent services in parallel and keep only payment authorization and final order creation in the synchronous path. Move price and tax calculation into the commerce engine's cart, and send everything else to the event bus.

State drift

Event-driven integration gives eventual consistency, so drift is expected. It becomes a defect when no one owns the field. We recommend one system of record per attribute: the PIM owns descriptions and attributes, the engine owns price, and the OMS owns stock and order state.

Consumers should be idempotent and process versioned events. Add a nightly reconciliation job that diffs the three systems and alerts on any mismatch rate you have set as a threshold.

Track three signals from the first release: trace depth on checkout, consumer lag per topic, and the reconciliation mismatch count. A fast-growing mismatch count usually points to a missed event or an unclear owner.

If you are designing these seams now, our API-first commerce service starts with the checkout call graph and data ownership map.

Composable vs headless commerce: Which to choose?

Choose headless commerce when one engine and one team own the stack; choose composable commerce when two or more domains need independent swap or scaling.

A headless frontend is the first step of both paths, so the real decision is how far behind it you split the backend. The headless commerce guide covers the frontend side in depth.

If you decide to go headless and need outside help with the build, this list of headless commerce agencies can help you shortlist vendors.

The two models side by side:

Headless is the better fit when:

• The engine's native catalog, pricing, promotions and checkout cover your requirements.
• One team owns the backend and the release cadence.
• The pain is storefront performance, design freedom or adding channels.

Composable is the better fit when:

• A PIM must feed several channels or markets with its own data model.
• The OMS or search needs replacing or scaling independently of checkout.
• Separate teams need separate release cycles for separate domains.

Composable adds integration work: contract tests between services, event handling and eventual consistency. Our judgement is that a team without capacity to own that layer should stay headless, because each extra vendor adds a failure point that someone must monitor.

Headless is also a sound first move on the composable path. Keep the headless frontend and its BFF, then use the strangler fig pattern to extract one capability at a time, starting with whichever domain hurts most.

Netguru builds both models, so the rule above follows your domain boundaries, not a preferred engagement type. For the build side, see our headless commerce development and API-first commerce services.

Composable vs monolithic commerce at a glance

Composable vs monolithic commerce is a spectrum, and Shopify Plus, SAP Commerce Cloud and VTEX sit in the middle as hybrids that expose APIs and support headless frontends but keep one commerce core.

Full MACH architecture sits at the far end, where every capability runs as its own service.

The three positions side by side:

The hybrid failure case is coupling two monoliths, such as Magento with Pimcore. Keeping both synchronized costs time and money on every update and security patch. When something breaks, the team first has to work out which system is at fault, which slows every fix.

The composable alternative integrates separate services over APIs: a commerce engine, a PIM such as Pimcore, Akeneo or inRiver, search such as Algolia or Elasticsearch, and payment gateways such as Stripe, Adyen or PayPal. Netguru builds at all three positions. The full trade-off analysis is in our composable vs monolith architecture comparison.

How to build a composable commerce stack: Which components to pick

Any packaged business capability can run as its own component. The usual candidates are the commerce engine, CMS, product information management (PIM), order management system (OMS), search and payments. The engine is the hub: commercetools, Saleor or Medusa can fill that role.

The sample stack below is an illustrative assumption for a mid-market retailer, not a recommendation. For each pair, the table lists the integration it needs, who owns it, and an early sign that the link is failing.

The OMS and search pairs run on events, so plan for eventual consistency. A product can briefly appear in search after the engine has already marked it unavailable, and the frontend needs a fallback for that gap.

Every pair needs one named owner. When a PIM sync breaks and the pair is unowned, merchandising blames engineering and engineering blames the vendor. Record the owner and the failure signs above in the API orchestration layer runbook, next to the retry and alerting rules.

When to split a capability out

Split a capability into its own component when all three conditions hold:

• The engine's built-in version blocks a requirement you have.
• A team exists that can run the replacement.
• You can name the owner of the new integration.

If any condition fails, keep the capability inside the engine.

Under that rule, a smaller team could start with the engine, PIM and search, and keep the CMS and OMS inside the engine until they outgrow them. How a PIM fits is worth settling first, because it feeds every other component.

For vendors and agencies that deliver stacks like this, see our list of composable commerce companies.

Benefits of composable commerce, and the caveat to each

Each benefit of composable commerce holds only under a specific condition, and that condition is usually where projects overspend. Gartner, which introduced packaged business capabilities as the unit of composition, forecast in 2020 that by 2023 organizations adopting a composable approach would outpace competitors by 80% in the speed of new feature implementation. That was a forecast, not a measured result.

That claim assumes the contracts between capabilities stay stable. The trade-offs side by side:

The last row is the cost side of every other row. Six vendors mean six SLAs, six upgrade cycles and six places for an incident to start, and a team of ten engineers may not absorb that.

We recommend choosing the two benefits your roadmap depends on and funding their conditions first. A retailer that needs weekly merchandising changes should pay for CMS preview and PIM governance before it pays for a third swappable component. Change speed is the benefit most teams buy for.

Is composable commerce worth it? A readiness scorecard

Composable commerce is worth it when you run several storefronts, have a team that can own integrations, and have outgrown your platform's roadmap. Below those thresholds, a monolith or hybrid platform usually costs less to run.

Score your situation against the table below. The thresholds are our own illustrative judgement, not industry benchmarks.

Five rows in the left column justify a phased migration, using the strangler fig pattern. Three or four point to a hybrid: keep a platform such as Shopify Plus, add a headless frontend, and swap out one component, usually search or PIM. Two or fewer means staying put.

Unclear cross-vendor incident ownership is a stop sign whatever the score. If checkout fails while the commerce engine, payment provider and orchestration layer each show green on their own status pages, one party in your organization must own diagnosis end to end.

MACH Alliance membership speaks to architectural principles, so it does not tell you who gets paged. Settle that in contracts and runbooks before launch.

The team-size row bends if a delivery partner operates the stack for you. In that case, test the partner's on-call model instead of your headcount.

What does composable commerce cost, and where are the hidden costs?

Composable commerce shifts cost from license fees to integration, observability, and ownership, so the total depends on how many vendors you connect and who carries the pager.

A commerce engine such as commercetools is one contract. Search, PIM, OMS, payments, and a headless frontend each add another, and each brings its own pricing model, release cycle, and security review. The license is the visible part of the budget. The rest shows up as engineering time.

The cost drivers side by side:

The integration layer is the largest recurring line. Each vendor ships updates and security patches on its own schedule, so the API orchestration layer and the event-driven integration behind it need contract tests, versioned schemas, and a named owner. Plan for the salaries of skilled engineers who run that layer, not only the build hours.

Coupling two monoliths carries the same overhead. A Magento and Pimcore pair has to stay synchronized through every update, and troubleshooting starts with working out which system is at fault. Composable multiplies that across a commerce engine, a PIM, a search engine such as Algolia, payment gateways such as Stripe or Adyen, and BNPL modules such as Klarna.

This cost shape applies less when you run a single storefront or lack a platform team. A hybrid platform such as Shopify Plus keeps more of the integrations on the vendor's side. We suggest estimating TCO by counting integrations and on-call rotations first, then comparing license quotes.

How to migrate from a monolith to composable commerce

Migrate from a monolith to composable commerce with the strangler fig pattern: put a routing layer in front, then extract search, content, product information management, and checkout, in that order. Each step follows Martin Fowler's strangler fig pattern, so the monolith keeps serving until the replacement proves itself.

Start with the routing layer. An API gateway or edge router decides per route which system answers, and a headless frontend or BFF renders the pages you migrate first. Design this layer and your event contracts before extracting anything. Our API-first commerce and headless commerce development services begin here.

The extraction order, from lowest to highest blast radius:

1. Search (Algolia or Elasticsearch). Search is read-only. Feed it from the monolith's catalog export, mirror live queries to both engines, and compare zero-result rate and click-through. Rollback is a feature flag.
2. Content (Contentful, Storyblok, or Strapi). Move editorial and landing pages route by route. Rollback is a route change at the gateway.
3. Product information management (Pimcore, Akeneo, or inRiver). Make the PIM the source of truth and sync one way to the monolith and the new commerce engine. Run a nightly reconciliation job to catch drift, because eventual consistency will show up as stale prices or attributes. The monolith keeps its own copy until cutover.
4. Checkout (commercetools or Medusa, with Stripe or Adyen). Checkout carries orders, tax, and payments, so move it last. Send a small cohort of new carts to the new engine, use idempotency keys on payment calls, and let in-flight carts finish where they started. Rollback routes new carts back to the monolith.

This order is our recommendation, not a standard. Reverse it when checkout conversion is the pain that justifies the project. Skip a separate PIM for a small catalog the commerce engine handles natively.

After checkout, the order management system is the next candidate, and the monolith can then be retired.

B2B composable commerce: When it fits

B2B commerce fits composable when quoting, account hierarchies and ERP-driven pricing exceed what a suite can configure. In that case, an order management system and an API orchestration layer let you model negotiated-sales logic once and reuse it across portals, sales-rep tools and marketplaces.

Our rule of thumb is to go composable when at least two of these hold:

• Quoting: multi-round quotes, approval chains or configure-to-order products that the suite handles only through custom code.
• Account hierarchies: parent-child buyer organizations with per-unit budgets, role-based approvals and contract-specific catalogs.
• ERP pricing: contract prices, tiered discounts and stock availability live in the ERP and must be read at request time, because a nightly sync produces stale quotes.

In the composable version, the ERP stays the pricing authority. The orchestration layer fetches contract prices on demand, product information management supplies catalog data, and the OMS handles split shipments and backorders. A commerce engine such as commercetools documents business units and quotes as API resources, so you configure them instead of building them.

If you have one price list, flat accounts and standard approvals, the B2B features in a suite or Shopify Plus will ship sooner and cost less to run. Composable adds integration ownership, and that only pays off when your sales process is the differentiator.

Composable commerce FAQ

Get a composable commerce estimate

A composable commerce estimate starts with scoping the first capability to separate from your current platform, usually order management, product information, search, or the storefront. Bring your current stack, your integration list, and the change you can't ship today, and we'll size a first phase around them.

Our engineers build on commercetools, VTEX, Saleor, Medusa, SAP Commerce Cloud and Shopify Plus, with Contentful, Strapi or Storyblok for content. Our Fluent Commerce development services cover order management when fulfillment is the bottleneck, and our commerce development work covers the wider scope.