MACH Architecture in SAP Commerce Cloud: What It Means in Practice

MACH stands for Microservices, API-first, Cloud-native and Headless. On a slide it is four boxes. In a project it is a set of choices, and SAP Commerce Cloud handles each of the four differently. Knowing where the line falls saves you from making architecture decisions based on vendor slides.

The short version: Commerce Cloud is a hybrid. Three principles are built in, the fourth comes through extensions.

TL;DR: SAP Commerce Cloud meets API-first (OCC REST APIs), cloud-native (a platform SAP operates for you) and headless (Composable Storefront or any custom frontend). Its backend is one Java application, so it is not microservices-based; SAP recommends building new custom logic as side-by-side extensions on SAP BTP. For most B2B projects that hybrid is enough. Pursue API-first and headless, take cloud-native as given, and add microservices only where a specific requirement needs them.

What does MACH stand for?

MACH is a set of four principles, promoted by the MACH Alliance:

• Microservices: business logic split into small, independently deployable services
• API-first: every function exposed through well-defined APIs before any user interface
• Cloud-native: built for cloud operation with automatic scaling, resilience and managed services
• Headless: frontend decoupled from backend, communicating only through APIs

They are not all-or-nothing. A platform can be strong on some and weaker on others. Which mix you need matters more than any badge on a vendor’s website. For the business question of when to assemble specialised services at all, see our guide to composable commerce in B2B.

M for microservices: a hybrid

Commerce Cloud’s backend is one Java application. Cart, checkout, pricing, search and order management run in the same process, and you deploy the platform as a unit, not module by module.

Microservices appear around it:

• Side-by-side extensions on SAP BTP. SAP’s recommended approach for new custom logic: build it as a standalone service on SAP BTP (Kyma runtime or Cloud Foundry) and call it through APIs, rather than extending the core.
• Third-party services. Payment, tax, search or personalisation run as independent services that Commerce Cloud calls.

In practice you do not get independent deployment of commerce modules, but you do get extensibility through external services. For most B2B implementations that is enough, and the single core has an advantage: contract prices, promotions and the order flow stay consistent in one place. Where the core really limited a project, the answer in our work has been the same each time: build that specific capability on BTP next to Commerce Cloud.

A for API-first: the strongest principle

The OCC (Omni Commerce Connect) REST APIs expose products, categories, carts, checkout, orders, customers, search and CMS content. Composable Storefront talks to Commerce Cloud exclusively through them, which is the best proof that they are complete enough to run a full shop. SAP documents the OCC extension-based architecture on SAP Help.

What makes the layer usable in projects:

• broad coverage of commerce operations, B2B included
• extensible: you add custom endpoints through your own extensions
• OpenAPI specifications and OAuth 2.0 authentication
• any frontend technology can consume it

One caveat: some administration and configuration tasks still need Backoffice. The API surface is built for commerce, not for complete system administration.

C for cloud-native: managed by SAP

SAP Commerce Cloud runs on infrastructure SAP operates for you. In practice that means:

• automatic scaling with traffic
• a built-in CDN for static assets and media
• deployments through Cloud Portal, with no direct server access
• separately provisioned environments and immutable build artifacts
• logs and metrics in the portal
• security patches and cumulative update releases from SAP

The trade-off is control. You cannot choose the database engine, tune the JVM beyond what SAP allows, or pick regions SAP does not offer. For most commerce workloads that is irrelevant; for a few edge cases it matters. Since mainstream maintenance for the on-premise product ended on 31 July 2026 (SAP Help), the cloud is the path forward for SAP Commerce; our post on what to do now that on-premise support has ended covers the options.

H for headless: built in

Composable Storefront (formerly Spartacus) is SAP’s Angular-based headless frontend (SAP Help). It talks to Commerce Cloud only through OCC, and storefront and backend deploy independently: you ship an Angular update without touching the Java backend.

What headless enables:

• any frontend framework (Angular, React, Vue, Next.js)
• the same APIs for web, mobile apps, kiosks and partner portals
• storefront releases independent of backend releases
• server-side rendering for speed and search engines

Often overlooked: even in headless mode, SmartEdit still manages page composition. Content managers create pages, slots and components in SmartEdit, and Composable Storefront renders them. Marketing changes layouts without a developer. If you prefer React or Next.js, our comparison of Composable Storefront vs React/Next.js explains the trade-offs. Distrelec is a reference for the headless route: after we decoupled its frontend, time-to-market for frontend changes dropped by 70%.

Should you go full MACH?

Not necessarily. MACH is a set of principles, not a creed. The useful question is which principles solve your specific problems.

API-first and headless are almost always worth pursuing. They give you frontend freedom and a clean integration strategy, including towards the ERP.

Cloud-native is a given for SAP Commerce now.

Microservices is where pragmatism matters most. The single backend works well for most implementations. If you need independent deployment or separate data stores for a capability, build it on BTP next to Commerce Cloud. Do not try to break the platform itself apart.

If you are weighing this against other platforms, our comparison of SAP, Salesforce and Adobe Commerce looks at architecture side by side. Or talk to our commerce architects about your setup.

FAQ

Is SAP Commerce Cloud a MACH platform?

Partly. It meets three of the four principles well: API-first through the OCC REST APIs, cloud-native as a platform operated by SAP, and headless through Composable Storefront or any custom frontend. The backend is one Java application, so it does not meet the microservices principle; SAP’s answer is side-by-side extensions on SAP BTP.

What is the difference between MACH and composable commerce?

MACH describes how the technology is built: microservices, APIs first, cloud-native operation, decoupled frontend. Composable commerce is the strategy of assembling specialised services into one commerce platform. You need MACH-style building blocks to compose, but using them does not make you composable.

Can I build a non-Angular frontend on SAP Commerce Cloud?

Yes. The OCC APIs are technology-neutral REST endpoints, so React, Vue, Next.js or Svelte work as well as SAP’s Angular-based Composable Storefront. You give up SAP’s prebuilt storefront components and gain full control over the frontend, including its maintenance.

Does MACH architecture improve performance?

It can. A headless frontend allows server-side rendering and edge caching, and a managed cloud platform scales with traffic. The risk is over-decomposition: many services calling each other add latency that a well-tuned single platform avoids. Measure the buying journeys that matter before and after a change.

Does going MACH change the cost of SAP Commerce Cloud?

The platform licence does not depend on the architecture you choose. Implementation and running costs do: custom services on SAP BTP or a custom frontend add build and maintenance effort. For many projects, the standard platform with Composable Storefront is the more economical start.