Composable Commerce and MACH Stack Architecture for Startups

MACH is an acronym coined by the MACH Alliance, and it stands for Microservices, API-first, Cloud-native, and Headless. Each letter represents an architectural principle, not a specific technology. Understanding what each principle actually demands from your engineering team is the first step toward deciding whether composable commerce belongs in your roadmap.

Microservices means each business capability runs as an independent service with its own data store, deployment pipeline, and scaling profile. Your search service does not share a database with your order management system. Your CMS does not compete for compute resources with your checkout flow. When Black Friday traffic spikes, you scale your product listing and cart services independently instead of throwing more hardware at a monolith that is 80% idle code.

API-first means every piece of functionality is exposed through a well-documented, versioned API before any frontend is built. This is not the same as "has an API." Shopify has an API. But Shopify was built UI-first, and the API was bolted on later. API-first platforms design the contract between services as the primary artifact. This matters because it means your frontend team, your mobile team, your third-party integrators, and your internal tools all consume the same stable interface.

Cloud-native means the services are designed to run in cloud infrastructure from the start. They use managed databases, object storage, container orchestration, and auto-scaling. They are not legacy applications that someone uploaded to an EC2 instance and called "cloud." Cloud-native services handle failure gracefully, scale horizontally, and deploy without downtime.

Headless means the frontend presentation layer is completely decoupled from the backend business logic. Your storefront is a standalone application, typically built with Next.js, Remix, or a similar framework, that fetches data from commerce APIs. You are not locked into a theme engine. You are not fighting template constraints. You own the entire customer experience from pixel to API call.

Together, these four principles form the foundation of composable commerce. But here is the critical insight most articles miss: MACH is a set of constraints, not a guarantee. You can follow every principle and still build a fragile, expensive mess if you get the orchestration wrong. The principles tell you how to structure the pieces. They do not tell you how to glue them together.

If monolithic platforms like Shopify, Magento, and BigCommerce work fine for most stores, why would anyone willingly take on the complexity of composable commerce? The answer is that monoliths work fine until they do not, and by the time you hit their limits, migration is painful and expensive.

The performance ceiling. A standard Shopify store with 15 apps installed loads in 3 to 5 seconds on mobile. Each app injects its own JavaScript, makes its own API calls, and adds its own render-blocking resources. You cannot fix this without removing apps, which means losing functionality. A composable architecture lets you consolidate those capabilities into purpose-built services that communicate server-side, keeping the frontend lean. Stores built on composable stacks routinely achieve sub-second load times, which translates directly into higher conversion rates.

The customization wall. Monolithic platforms give you customization within their model. Shopify lets you build custom themes, but you cannot change how checkout works unless you are on Shopify Plus. Magento lets you extend almost anything, but the extension mechanism involves overriding PHP classes in a dependency graph so tangled that upgrading between major versions can take months. Composable commerce does not have a customization wall because each service is independently replaceable. If your checkout provider cannot handle split payments to multiple vendors, you swap it for one that can.

The vendor lock-in trap. Every feature you build on a monolithic platform increases your switching cost. Your product data lives in their schema. Your order history lives in their database. Your customer accounts live behind their authentication system. After two years on Shopify, migrating away means extracting and transforming hundreds of thousands of records, retraining your operations team, and rebuilding every integration. Composable architecture distributes this risk across multiple vendors. Replacing your search provider is a bounded project, not a full replatform.

The pricing squeeze. Shopify charges transaction fees on every sale unless you use Shopify Payments. Magento Commerce (Adobe Commerce) charges license fees that scale with revenue. BigCommerce charges more per plan as your annual sales grow. At $10M in annual revenue, these fees become material. A composable stack built on open-source engines like Medusa or Saleor with Stripe for payments eliminates platform revenue share entirely.

None of this means monoliths are bad. They are excellent for getting to market quickly with limited engineering resources. The problem is that the very thing that makes them easy to start with, tight coupling and opinionated defaults, is the same thing that makes them hard to scale past. If you are reading this article, you are probably at the inflection point where the monolith is starting to hold you back.

Composable commerce is not just headless commerce with extra steps. It is a fundamentally different philosophy about how to build a commerce system. The core idea is simple: instead of buying one platform that does everything adequately, you select the best tool for each individual capability and compose them into a unified system.

Think of a monolithic platform as a pre-built house. You get a kitchen, bedrooms, a bathroom, all designed to work together. But the kitchen appliances are mid-range, the bathroom fixtures are builder-grade, and you cannot move the walls. Composable commerce is more like hiring an architect and selecting each component yourself. You pick a Wolf range for the kitchen, Toto fixtures for the bathroom, and custom millwork throughout. The result is better at every layer, but the coordination cost is higher.

Here are the key commerce capabilities you need to compose, and the leading vendors for each:

Commerce Engine (Catalog, Cart, Checkout, Orders)

This is the core transactional layer. It manages your product data model, shopping cart logic, checkout orchestration, and order lifecycle. Medusa is the strongest open-source option for teams with Node.js and TypeScript expertise. It is modular, fully self-hosted, and charges no transaction fees. Saleor is the best choice for teams that prefer Python and GraphQL. commercetools is the enterprise-grade SaaS option with a consumption-based pricing model. For a detailed breakdown, read our headless commerce platform comparison.

Search and Product Discovery

Algolia remains the gold standard for hosted search with excellent relevance tuning, merchandising tools, and analytics. It gets expensive at high query volumes. Typesense is the open-source alternative that delivers comparable performance at a fraction of the cost when self-hosted. It now supports vector search for semantic product discovery. Meilisearch is another open-source contender that prioritizes developer experience and ease of setup.

Content Management (CMS)

Sanity offers real-time collaborative editing, a flexible schema system, and GROQ, a query language that is surprisingly powerful for content-heavy commerce sites. Contentful is the more established option with a larger ecosystem of integrations. Strapi is the open-source headless CMS that gives you full control over the content API. For landing pages, marketing content, and editorial commerce experiences, a dedicated CMS is far superior to the basic page builder in any commerce platform.

Payments

Stripe dominates for good reason. The API design is best-in-class, the documentation is exceptional, and the feature set covers everything from simple card payments to complex marketplace payouts with Stripe Connect. Adyen is the alternative for enterprise brands that need global payment method coverage across 50+ countries. For most startups, Stripe is the obvious choice.

Order Management (OMS)

For simple fulfillment workflows, your commerce engine handles orders just fine. When you need multi-warehouse routing, dropship vendor management, or complex return flows, a dedicated OMS like Orderhive or Brightpearl earns its keep. Some teams build custom order orchestration on top of Temporal or AWS Step Functions when their workflow logic is truly unique.

Product Information Management (PIM) and Digital Asset Management (DAM)

Akeneo is the leading open-source PIM for managing product data across channels. Cloudinary handles image and video optimization, transformation, and delivery with a CDN built for media-heavy commerce sites. If you have fewer than 5,000 SKUs, you probably do not need a standalone PIM. Your commerce engine's product model is sufficient.

The composable approach works because each of these vendors focuses exclusively on their capability. Algolia's search relevance is better than any monolith's built-in search. Sanity's content editing experience is better than any commerce platform's page builder. Stripe's payment coverage is better than any platform's native payments. You get best-in-class at every layer.

Here is where composable commerce gets hard. You have selected best-of-breed tools for commerce, search, CMS, payments, OMS, PIM, and DAM. Now you need them to talk to each other reliably. This orchestration layer is where most composable implementations either succeed spectacularly or fail expensively.

API Gateway Pattern

Your frontend should not call eight different APIs directly. That creates a tangled web of authentication tokens, error handling logic, and network requests that makes the storefront brittle and slow. Instead, place an API gateway between your frontend and your backend services. The gateway acts as a single entry point that routes requests to the appropriate service, aggregates responses, and handles cross-cutting concerns like authentication, rate limiting, and caching.

For most startup-scale composable stacks, a lightweight API gateway built with Next.js API routes or a dedicated Node.js service (using something like Express or Fastify) is sufficient. You do not need Kong or AWS API Gateway on day one. Your gateway fetches product data from Medusa, enriches it with content from Sanity, and returns a single unified response to the frontend. This is sometimes called the Backend for Frontend (BFF) pattern, and it is arguably the most important architectural decision in a composable stack.

Event-Driven Architecture for Commerce

Synchronous request-response works for reads (fetching a product page) but breaks down for writes that trigger cascading side effects. When a customer places an order, you need to: charge the payment, decrement inventory, notify the OMS, send a confirmation email, update the search index, and fire analytics events. Doing all of this synchronously in a single API call is fragile. If the email service is slow, the entire checkout stalls.

Event-driven architecture solves this with a message broker. When an order is placed, the commerce engine publishes an "order.created" event to a message queue (AWS SQS, RabbitMQ, or a managed Kafka instance). Each downstream service subscribes to the events it cares about and processes them independently. The payment service listens for "order.created" and charges the card. The inventory service decrements stock. The notification service sends the email. If the email service goes down for five minutes, the message sits in the queue and gets processed when the service recovers. No data is lost, no checkout is blocked.

For startups, keep it simple. Use AWS SQS or Google Cloud Pub/Sub. You do not need Kafka unless you are processing tens of thousands of events per second. A straightforward pub/sub model with dead-letter queues for failed messages covers 90% of commerce event-driven patterns.

Data Consistency Across Services

When product data lives in Medusa, content lives in Sanity, and search lives in Typesense, keeping everything in sync becomes a real concern. The standard approach is eventual consistency through webhooks and events. When a product is updated in Medusa, a webhook fires. Your sync service receives the webhook, fetches the updated product, enriches it with content from Sanity, and pushes the result to Typesense. There is a brief window (usually seconds) where the search index is stale. For commerce, this is acceptable. Customers will not notice a two-second delay between a price change in the admin panel and the updated price appearing in search results.

Where you need strong consistency is the transactional path: cart, checkout, and payment. These operations must be synchronous and atomic. Never use eventual consistency for money. Your checkout flow should make synchronous API calls to your commerce engine and payment processor, confirm the transaction is complete, and only then publish events for downstream processing.

This is the section that most composable commerce advocates skip, and it is the most important one for startups. Composable architecture is not universally better. It is better for specific situations, and actively worse for others.

If you are under $1M in annual revenue, composable commerce is almost certainly overkill. At that stage, your primary constraint is not technology. It is finding product-market fit, acquiring customers, and iterating on your offering. Every hour your engineering team spends wiring up event buses and configuring API gateways is an hour not spent on customer-facing features. A Shopify store with a solid theme gets you to market in weeks. A composable stack takes months.

If your catalog has fewer than 1,000 SKUs and your checkout flow is standard (single currency, single warehouse, no B2B pricing, no subscriptions), you do not need composable. Shopify or BigCommerce handles this perfectly. The complexity of composable architecture only pays off when your business logic outgrows what a monolith can express.

If your team has fewer than three engineers, the operational burden of composable commerce will consume most of your capacity. You are running and monitoring multiple services, managing multiple vendor relationships, and debugging issues that span service boundaries. A monolithic platform lets a small team punch above its weight because the platform vendor handles infrastructure, security patches, and uptime.

Here is the honest calculus. Composable commerce makes sense when:

• You have unique business logic that monolithic platforms cannot support (complex pricing, multi-vendor marketplaces, custom fulfillment workflows)
• Performance is a measurable revenue driver (your conversion data shows that speed improvements directly increase sales)
• You have the engineering team to build and maintain a distributed system (at least 3 to 5 backend engineers)
• You are at a scale where platform fees become a significant line item (typically $5M+ in annual revenue)
• You need true omnichannel capabilities (web, mobile app, in-store, B2B portal) from a single backend

If none of these apply, start with Shopify or a similar monolith and migrate later. The migration path exists, and it is less expensive than building composable from scratch before you need it. We cover the costs in detail in our headless commerce costs guide.

The most common composable commerce project is not a greenfield build. It is a migration from Shopify (or Magento, or BigCommerce) to a composable stack. Done right, this migration is incremental, not a big-bang replatform. The strangler fig pattern, where you gradually replace pieces of the monolith with composable services, dramatically reduces risk.

Phase 1: Decouple the Frontend (Weeks 1 to 8)

Build a new Next.js storefront that consumes the Shopify Storefront API (or Hydrogen framework). Your backend stays on Shopify. Your operations team keeps using the same admin panel. The only change is the customer-facing frontend, which is now a standalone application you fully control. This phase alone delivers the performance gains (sub-second page loads) and design freedom that drive most replatforming decisions.

This is the lowest-risk starting point because you are not touching the transactional backend. If something goes wrong with the new frontend, you can revert to the Shopify theme in minutes.

Phase 2: Extract Search (Weeks 6 to 12)

Replace Shopify's built-in search with Typesense or Algolia. Set up a product sync pipeline that indexes your Shopify catalog into the external search engine. Your new frontend queries the search service directly for product listings, autocomplete, and faceted filtering. This gives you dramatically better search relevance, semantic search capabilities, and merchandising control.

Phase 3: Extract Content (Weeks 10 to 16)

Move marketing content, landing pages, and editorial content from Shopify's basic pages and blog system to Sanity or Contentful. Your frontend fetches content from the CMS API and product data from Shopify, composing them into rich, content-driven shopping experiences that Shopify's theme engine simply cannot produce.

Phase 4: Replace the Commerce Engine (Weeks 14 to 24)

This is the big one. Migrate your product catalog, customer accounts, and order management from Shopify to Medusa or Saleor. This phase requires careful data migration, testing of checkout flows, and coordination with payment processors. Run both systems in parallel during the transition. Route a percentage of traffic to the new backend, monitor conversion rates and error rates, and gradually shift traffic as confidence builds.

The key insight is that you do not have to do all four phases. Many businesses stop after Phase 1 or Phase 2 because they get the performance and flexibility they need without the cost of a full backend migration. If you want to learn how to build the frontend layer, our headless commerce storefront guide walks through the architecture in detail.

Let's talk money. Composable commerce has a reputation for being expensive, and that reputation is partially deserved. But the full picture is more nuanced than "composable costs more."

Upfront Build Cost

A production-ready composable stack (Medusa + Typesense + Sanity + Stripe + Next.js frontend + API gateway + event-driven sync pipeline) takes 4 to 6 months to build with a team of 3 to 4 experienced engineers. At $150 to $200 per hour for senior full-stack developers, you are looking at $200K to $400K in development cost. A comparable Shopify Plus store with a custom theme and standard apps costs $50K to $100K.

The composable stack costs 2x to 4x more upfront. That is a fact, and anyone who tells you otherwise is selling something.

Ongoing Operational Cost

Here is where the math shifts. A composable stack built on open-source tools (Medusa, Typesense, Strapi) running on AWS or Railway costs $500 to $2,000 per month in infrastructure. Shopify Plus costs $2,300 per month minimum, plus transaction fees (0.15% to 0.5% on non-Shopify Payments volume), plus app subscription fees ($200 to $500/month for reviews, search, email, loyalty, etc.).

At $5M in annual revenue, a Shopify Plus store with typical app usage costs roughly $45,000 to $60,000 per year in platform and app fees. The composable stack costs roughly $12,000 to $24,000 per year in infrastructure, plus the cost of engineering time for maintenance (budget 10 to 20 hours per month). By $10M in annual revenue, the composable stack is meaningfully cheaper on an ongoing basis.

A Real-World Architecture Example

Here is a composable stack we have deployed for a direct-to-consumer brand doing $8M in annual revenue with 12,000 SKUs across three geographic regions:

• Frontend: Next.js 15 on Vercel, using React Server Components for product pages and static generation for category pages. Edge middleware handles geo-routing and A/B testing.
• Commerce Engine: Medusa v2 on AWS ECS (Fargate), with PostgreSQL on RDS. Handles catalog, cart, checkout, orders, and multi-currency pricing.
• Search: Typesense on a dedicated cloud instance. Product sync runs every 60 seconds via a cron job that pulls from Medusa and enriches with content from Sanity.
• CMS: Sanity for marketing pages, product editorial content, and promotional banners. Content editors publish directly without involving engineering.
• Payments: Stripe with Stripe Elements embedded in the Next.js checkout flow. Apple Pay and Google Pay enabled through the Payment Request API.
• Email: Resend for transactional emails (order confirmation, shipping updates) triggered by Medusa webhooks routed through SQS.
• API Gateway: A lightweight Fastify BFF service on ECS that aggregates Medusa product data with Sanity content and Typesense search results into a single response for the frontend.
• Event Bus: AWS SQS with dead-letter queues. Medusa publishes order, inventory, and customer events. Downstream consumers handle search re-indexing, email triggers, and analytics.

Total monthly infrastructure cost: $1,400. Total monthly Vercel cost: $200. Compared to the Shopify Plus plan with equivalent app functionality, this architecture saves the client roughly $30,000 per year while delivering sub-800ms page loads and complete control over every customer touchpoint.

Composable commerce is not for every startup. But for brands that have outgrown their monolith, have the engineering capacity to operate a distributed system, and need the flexibility to build differentiated shopping experiences, it is the architecture that scales with you instead of against you. If you are evaluating whether this approach fits your business, book a free strategy call and we will map out the right architecture for your specific requirements.