Growth Notes

Composable Commerce

Tags: web-dev commerce concept

Composable Commerce

Date: 2026-08-17

Assembling a commerce stack from specialist vendors joined by APIs, rather than buying one suite that does everything adequately. The pitch is best-of-breed; the bill is integration, and unlike a licence it arrives every year in engineering time.

What it is

Composable commerce is an architecture where each capability — catalogue, cart, checkout, payments, search, content, promotions, order management — is a separately chosen service, and the storefront calls all of them.

The vocabulary usually arrives as MACH, a vendor acronym for Microservices, API-first, Cloud-native and Headless. Treat it as a marketing label for the four properties above rather than as a technical standard — there’s nothing to comply with.

SUITE                                COMPOSABLE

┌──────────────────────────┐         ┌─────────┐ ┌─────────┐ ┌─────────┐
│                          │         │Catalogue│ │ Search  │ │   CMS   │
│   one vendor:            │         └────┬────┘ └────┬────┘ └────┬────┘
│   catalogue, cart,       │              │           │           │
│   checkout, CMS, search, │         ┌────┴───────────┴───────────┴────┐
│   promotions, OMS        │         │      your storefront +          │
│                          │         │      the glue you now own       │
└────────────┬─────────────┘         └────┬───────────┬───────────┬────┘
             │                            │           │           │
         storefront                  ┌────┴────┐ ┌────┴────┐ ┌────┴────┐
                                     │Checkout │ │Payments │ │  OMS    │
                                     └─────────┘ └─────────┘ └─────────┘

one integration, one upgrade path     six integrations, six upgrade paths,
one vendor's opinion about everything  and the glue is a system you maintain

The box labelled “the glue you now own” is the whole subject. It doesn’t appear in any vendor’s diagram and it’s where the cost lives.

What it actually buys

  • Replaceable parts. Swapping search is a project; in a suite it’s a replatform — Replatforming
  • Escaping one vendor’s worst component. Suites are uneven, and the weak module is usually the one closest to revenue
  • Independent release cadence. The content team ships without waiting on a commerce release
  • Buying the thing you’re differentiated on. Most retailers need excellent search and adequate order management, and a suite prices them identically

What it costs

  • Integration is now a permanent team. Six vendors, six APIs, six auth models, six rate limits, six sets of breaking changes on someone else’s schedule — Integration Patterns, Deprecation
  • No one owns the customer journey end to end. When checkout fails, the answer is in four systems and each vendor’s support can see one
  • Data consistency becomes yours. A suite guarantees the cart and the catalogue agree about price. Composed, that’s Eventual Consistency and you’re writing the reconciliation
  • Latency compounds. Each call is a network hop; a page needing five of them serially is slow before you’ve rendered anything — Backend for Frontend exists largely to fix this
  • Total cost is rarely lower. Several specialist subscriptions plus the engineering to join them, versus one licence

The decision

The useful question isn’t “composable or suite” — it’s which single capability is worth owning the integration for.

SituationShape that fits
Standard catalogue, standard checkout, small teamSuite. Composable is an expensive way to rebuild what you were given
One capability is genuinely a differentiatorSuite plus that one thing, headless — Headless Architecture
Multi-brand, multi-region, genuinely different models per marketComposable earns it
Migrating off a suite you’ve outgrownComposable incrementally — The Strangler Pattern, never a big-bang rebuild

Composable is a spectrum, not a state. Almost every real stack is a suite with two or three pieces replaced, and that’s usually the right answer rather than a compromise.

Where it bites

  • Checkout is the piece to think hardest about. It’s the most regulated, most conversion-sensitive and most tightly coupled to payments — Checkout Instrumentation Constraints
  • Measurement fragments with the stack. Each service emits its own events with its own identifiers, and nothing joins them unless you build it — Identity Stitching, Event Taxonomy Design
  • Promotions cut across everything. A discount touches catalogue, cart, checkout and order management, which is why it’s the integration that usually breaks first

Graph View

Backlinks