Topic
Composable Architecture
Composable architecture is a system design approach that assembles applications from independently deployable, API-connected components rather than a single monolithic platform.
Composable architecture assembles a platform from independently deployable, API-connected components instead of one monolithic suite. Each component can be replaced without rebuilding the system. It follows MACH principles: Microservices, API-first, Cloud-native, and Headless.
Most writing about composable commerce is about platform selection. It shouldn't be. Choosing one commerce engine over another is a procurement decision that takes a quarter; designing the connective tissue between your systems is an architecture decision you live with for a decade.
The components are the easy part. Every vendor in this space has a competent API. What decides whether a composable platform works is the integration layer: how data moves between commerce, ERP, and the data warehouse, what happens when a message fails at 2am, and who can reason about the flow six months after it was built.
I run this architecture in production at an Australian omnichannel retailer with 50+ locations: a headless commerce engine, an ERP as the source of truth, an orchestration tier between them, a server-rendered storefront, and a cloud warehouse underneath. What follows is written from operating it, not from evaluating it.
Key concepts
The vocabulary that comes up most in this area, defined.
| Term | Definition |
|---|---|
| MACH | Microservices, API-first, Cloud-native, Headless. The four properties that make a component swappable rather than embedded. |
| Integration layer | The orchestration tier that moves data between systems. In practice the most consequential and least discussed part of a composable platform. |
| Source of truth | The one system that owns a given data domain. Composable architectures fail when two systems both believe they own inventory. |
| Headless commerce | Separating the commerce engine from the presentation layer, so the storefront can be rebuilt without touching pricing, cart, or catalogue. |
| API contract | The agreed shape of data between two systems. Versioned contracts are what let components be replaced independently. |
Articles on composable architecture
No articles on this topic yet. The first ones are in progress. Leave your email and I'll let you know when they land.
Frequently asked questions
Composable commerce architecture is an approach to building e-commerce systems using interchangeable, best-of-breed components connected through APIs. It follows MACH principles: Microservices, API-first, Cloud-native, and Headless.
Headless commerce separates the storefront from the commerce engine. Composable commerce goes further: every capability: cart, search, payments, ERP: is an independently replaceable component, not just the frontend.
It depends on whether you need to change systems independently. If your commerce, ERP, and data roadmaps move at different speeds, composability pays for itself. If they don't, a suite is cheaper to operate.
The integration layer. Individual components are well documented and well supported. Data consistency, error handling, and failure recovery across components are where composable platforms actually succeed or fail.
MACH stands for Microservices, API-first, Cloud-native, and Headless. It describes the four technical properties that make a system component independently deployable and replaceable.