MACH Architecture Ecommerce: How the 4 Layers Actually Integrate

A MACH architecture in ecommerce is built from four responsibility layers: a frontend layer that renders the storefront, a commerce backend that holds catalog, pricing and carts, an omnichannel / order management system (OMS) that orchestrates orders across channels, and a discovery layer for search, recommendations and merchandising. The architecture doesn't become clean because every layer is swappable. It becomes clean because the contracts between the layers are explicit: who calls whom, over which API, with which data model. That is exactly where four microservices either turn into a working stack or into an integration tangle held together by five layers of glue code.

This post wires the four layers on a concrete, DACH-ready stack: frontend with Laioutr, backend with Emporix, omnichannel OS with Nekom, discovery with BatteryIncluded. Not a generic "what is composable" piece, but the question of which contracts run at the four seams.

Layer 1 - Frontend: Laioutr as a Frontend Management Platform

The frontend layer is the only layer your customer sees directly, and the layer that gets rebuilt most often when the backend changes. Laioutr is not yet another visual builder here. It is a Frontend Management Platform (FMP) - the category we define with the term itself (Laioutr-coined). The shipped storefront is a real Nuxt app with SSR and edge delivery, not generated HTML output from a builder DSL.

The decisive integration point sits one level down: Orchestr, the unified data layer. Orchestr normalizes product, inventory, category and order data from whichever backend into a single, GraphQL-consumable schema. The frontend components talk to that one schema, not to the raw backend API. That is why a backend change is not a frontend rewrite: the contract the component knows stays stable, even when Emporix behind it is swapped for a different backend.

If you want to see the layer in detail, the composable headless frontend hub is the entry point into the Nuxt foundation and the Orchestr layer.

Layer 2 - Backend: Emporix as the Commerce Engine

Emporix delivers the commerce domain: catalog, pricing, cart, checkout logic, B2B structures. As an API-first backend, Emporix is not built for one specific frontend. It exposes its domain as services. That is the precondition for wiring it to Laioutr.

The frontend-to-backend contract: Orchestr runs an Emporix connector that maps the Emporix REST / catalog APIs onto the internal Orchestr schema. Concretely: product queries, price resolution and cart mutations run through the connector, not through hand-written glue code in the storefront. The frontend component requests product, price, cart in the Orchestr schema, the connector translates that into Emporix calls and the Emporix response back into the normalized model. Custom Emporix fields with no standard mapping are passed through over a GraphQL fallback instead of breaking the schema.

This connector mechanic is Pillar-2 substance: the dedicated headless frontend for Emporix page describes the mapping and the supported entities in detail.

Layer 3 - Omnichannel OS: Nekom for Order Orchestration

As soon as orders arrive from more than one channel - web storefront, POS, marketplace, phone - the stack needs a layer that collects, routes and reconciles orders against inventory across channels. Nekom owns this order management and omnichannel orchestration: stock availability across warehouses and stores, order routing, returns, fulfillment status.

The backend/frontend-to-OMS contract runs at two points. First, at checkout: when an order is created in the storefront (Laioutr Checkout) or in Emporix, it is handed to Nekom as the orchestrating instance - typically via an order event or an order-create call. Second, at the availability read: the storefront should show real, cross-channel availability, not just the stock level of a single backend. Here Orchestr reads Nekom's inventory / availability endpoint and surfaces it as a field in the normalized product schema for the component. The clear rule: Emporix stays the source of truth for catalog and pricing, Nekom becomes the source of truth for availability and order status. Skip that separation and you build yourself two competing inventory truths.

Layer 4 - Discovery: BatteryIncluded for Search and Recommendations

Discovery is the layer that decides what the customer even finds: search, autocomplete, recommendations, merchandising rules. BatteryIncluded indexes the catalog and returns relevance-ranked results plus recommendation slots.

The discovery-to-frontend contract is deliberately decoupled from the catalog read. Discovery needs a current index, so the Emporix catalog (including Nekom availability for out-of-stock filtering) flows into BatteryIncluded - either by feed sync or event-driven on catalog changes. In the frontend, the search / listing component then calls the BatteryIncluded search endpoint, not Emporix. Through the Laioutr App Store this discovery provider is connected click-to-connect, instead of running an engineering sprint per integration. The result: search and product lists run over the specialized discovery layer, product detail and cart over the catalog layer, and both scale independently.

How the Four Contracts Work Together

In total there are four explicit contracts, all mediated by Orchestr as the frontend-side broker:

1. Frontend to backend (catalog/cart): Orchestr schema against the Emporix connector.
2. Frontend/backend to OMS (order/availability): order event to Nekom, availability read from Nekom into the Orchestr schema.
3. Catalog to discovery (index): Emporix catalog plus Nekom availability as a feed into BatteryIncluded.
4. Discovery to frontend (search): search / recommendation calls against BatteryIncluded, connected via the App Store.

The point is not that everything talks to everything. The point is that every layer has one clear source of truth and the storefront knows only a normalized schema. Treat the frontend layer as the orchestrating tier and your architecture decisions stay reversible - backend, OMS or discovery can be swapped later without touching the components. More on the frontend layer as a composable building block in the composable digital experience platform hub.

What You Gain: Wired vs. a Glue-Code Tangle

• Aspect | Wired directly (glue code per layer) | Via the frontend Orchestr layer
• Backend change | frontend rewrite, every component affected | swap the connector, schema stays stable
• Availability source | inconsistent, often two competing inventory truths | Nekom as single source of truth, one schema field
• Discovery integration | custom integration sprint per provider | click-to-connect via the App Store
• Data model in the frontend | n raw backend APIs | one normalized GraphQL schema
• Performance ownership | tuned per layer separately | Core Web Vitals as a platform property

The performance row is not a footnote: when the frontend layer owns data aggregation, it can also own the rendering budget. How Laioutr treats Core Web Vitals as an architecture property instead of a quarter-end optimization is on the performance and Core Web Vitals product page.

FAQ

Do I strictly need all four layers separated for a MACH architecture? No. You need clean contracts where responsibility changes. A smaller stack can keep catalog and discovery together. As soon as search relevance, a cross-channel OMS or a backend change become real, the layer separation pays off.

Why does orchestration sit in the frontend layer and not the backend? Because the frontend layer iterates most often and gets rebuilt most often. When normalization sits there, the component data model stays stable while backend, OMS and discovery behind it remain swappable.

What happens to custom fields with no standard mapping? They pass through a GraphQL fallback in the connector instead of breaking the normalized schema. Standard entities get mapped, special cases stay passable.

Next Step

If you are planning a composable stack in the DACH market or want to decouple an existing one: we will walk you through the 4-layer wiring on your concrete backend. Book a technical architecture session via the composable headless frontend page, or read in parallel how we correct common wiring mistakes and FMP patterns in our Insights piece Composable Stack Correction: engineering patterns for FMP.

About the author: Sebastian is co-founder and CTO of Laioutr and owns the technical voice. His position: performance and component discipline are architecture properties, not downstream optimizations - one UI library instead of theme forks, one normalized schema instead of glue code, built for co-authoring between humans and AI agents. We build Laioutr so frontend teams keep control of their layer without rebuilding the backend.