What is MACH and Who Defined it

MACH is an acronym coined by MACH Alliance, an association of technology vendors founded in 2020 by commercetools, Contentful, EPAM Systems and others. Not it is a product — it is a set of architectural principles for building systems modern enterprise.

  • M — Microservices: each business function is an independent service
  • A — API-first: Each service exposes well-defined APIs as its primary interface
  • C — Cloud-native: Built for public cloud, with elastic scaling and managed services
  • H — Headless: frontend and backend are decoupled

The fundamental idea is the best-of-breed: instead of buying a single suite that does everything (mediocre), choose the best service for each function and compose a platform tailor-made. The best search engine for products (Algolia), the best checkout (Stripe), the best CMS (Contentful), the best PIM (Akeneo).

The Four MACH Dimensions in Detail

Microservices: Decomposition for Bounded Context

In a MACH architecture, the commerce domain is decomposed into aligned independent services ai bounded context of Domain-Driven Design: 

// Esempio di decomposizione in microservizi commerce

const MACH_SERVICES = {
  // Servizi core commerce
  catalog: 'Gestione prodotti, categorie, attributi, varianti',
  pricing: 'Regole di prezzo, sconti, tier pricing, valute',
  inventory: 'Stock real-time, warehouse, backorder',
  cart: 'Sessioni di carrello, regole di promozione',
  checkout: 'Checkout flow, address validation, ordine',
  payments: 'Processing pagamenti, rimborsi, split payments',
  fulfillment: 'Gestione spedizioni, tracking, resi',

  // Servizi supporto
  search: 'Full-text search, filtri, ranking (Algolia)',
  recommendations: 'Prodotti correlati, personalization',
  cms: 'Contenuto editoriale, landing page (Contentful/Sanity)',
  pim: 'Product Information Management (Akeneo)',
  loyalty: 'Punti, rewards, programmi fedeltà',
  notifications: 'Email, SMS, push notifications',
};

API-First: Contract Before Implementation

In an API-first system, the API is the contract that is defined Before of the implementation. Each team can develop its own service independently because the contract API is already defined. 

// OpenAPI spec per il Catalog Service
openapi: 3.1.0
info:
  title: Catalog Service API
  version: 2.0.0

paths:
  /products:
    get:
      summary: Lista prodotti con paginazione e filtri
      parameters:
        - name: cursor
          in: query
          schema:
            type: string
        - name: category
          in: query
          schema:
            type: string
        - name: priceMin
          in: query
          schema:
            type: number
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ProductPage'

  /products/{id}:
    get:
      summary: Dettaglio prodotto singolo
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
        '404':
          $ref: '#/components/responses/NotFound'

Cloud-Native: Elastic Scaling and Managed Services

Cloud-native doesn't mean "runs on the cloud" — it means designed specifically to exploit cloud capabilities: automatic horizontal scaling, fault tolerance, observability integrated:

  • Docker containers orchestrated by Kubernetes (or Lambda Functions for event-driven loads)
  • Managed databases (Cloud Spanner, RDS, DynamoDB) instead of self-managed instances
  • Event bus managed (AWS EventBridge, Google Pub/Sub) for asynchronous communication
  • Global CDN for frontend delivery
  • Automatic circuit breaker and retry for resilience

Headless: Frontend Free from Backend

The H dimension of MACH has already been explored in the first article of the series: the frontend consumes API, it is not generated by the backend. In a MACH architecture completes this often means a BFF (Backend for Frontend) to optimize the API for i specific clients: 

// BFF Pattern: GraphQL aggregation layer
// Aggrega chiamate a più microservizi in un'unica risposta ottimizzata

type Query {
  productPage(
    category: String
    cursor: String
    filters: [FilterInput!]
  ): ProductPageResult!
}

type ProductPageResult {
  products: [ProductSummary!]!
  facets: [FacetGroup!]!       # da Algolia
  recommendations: [ProductSummary!]!  # da recommendation service
  pageInfo: PageInfo!
}

// Il resolver fa chiamate parallele a catalog, search e recommendations
const resolvers = {
  Query: {
    productPage: async (_, args) => {
      const [products, facets, recs] = await Promise.all([
        catalogService.getProducts(args),
        searchService.getFacets(args),
        recommendationService.get(args.category),
      ]);
      return { products, facets, recommendations: recs, pageInfo: products.pageInfo };
    },
  },
};

MACH vs Monolith: The Real Comparison

MACH vs Monolith: When It's Better What

  • Monolith managed (Shopify, WooCommerce): time to market in weeks, small team, low costs — ideal for GMV < 5M EUR/year
  • Partial MACH (headless + best-of-breed): gradual flexibility, medium team — ideal for GMV 5-50M EUR/year with specific needs
  • Full MACH: maximum flexibility, high costs, large team — justified for GMV > 50M EUR/year or specific enterprise requirements

MACH Governance and Anti-pattern

The most common mistake in MACH implementations is fragmenting too much without governance:

MACH Anti-pattern to Avoid

  • Premature microservices: Decompose into 20 services when handling 1000 orders/month is pure over-engineering. Start with a modular monolith, just decompose the parts that scale differently.
  • No versioned API contracts: Without API versioning, every team will break others in deployment. Adopt OpenAPI 3.1 + semantic versioning.
  • Cascaded synchronous calls: A request that calls 5 services in sequence accumulate latency. Use parallel calls where possible, CQRS pattern for heavy reads.
  • Shared database: If two MACH services share the database, they are not truly independent. Each service must have its own datastore.

Implement MACH Incrementally

You don't need to migrate to MACH all at once. The strangler fig pattern approach it is recommended:

  1. Phase 1: Add a headless layer on top of the existing monolith. The frontend new calls API, the monolith generates the API via REST/GraphQL layer. No changes to the core.
  2. Phase 2: Pull the first microservice for the function with the most needs specifications (often: search or inventory). The monolith continues to handle the rest.
  3. Phase 3: Continue extraction service by service, removing gradually the dependence on the monolith.

Conclusions

MACH is an architectural aspiration, not a checklist. The API-first and headless principles they bring real value even in partial implementations. The decomposition into microservices and the cloud-native complete the picture but require organizational maturity.

In the next articles we will explore the concrete implementations: Shopify Hydrogen for those who want headless on managed infrastructure, Medusa.js for those who prefer self-hosted open-source, e Saleor for Python teams with native GraphQL needs.

Previous article ← Headless Commerce: What is it
Next in the series Shopify Hydrogen and Oxygen →