Wat is MACH en wie heeft het gedefinieerd?

MACH is een acroniem bedacht door MACH-alliantie, een vereniging van technologieleveranciers opgericht in 2020 door commercetools, Contentful, EPAM Systems en anderen. Niet het is een product – het is een reeks architecturale principes voor bouwsystemen moderne onderneming.

  • M — Microservices: elke bedrijfsfunctie is een onafhankelijke dienst
  • A — API-first: Elke service stelt goed gedefinieerde API's ter beschikking als primaire interface
  • C — Cloud-native: gebouwd voor de publieke cloud, met elastische schaalbaarheid en beheerde services
  • H — Headless: frontend en backend zijn ontkoppeld

Het fundamentele idee is de beste van het ras: in plaats van een enkele suite te kopen die alles doet (middelmatig), kies voor elke functie de beste service en stel een platform samen op maat gemaakt. De beste zoekmachine voor producten (Algolia), de beste kassa (Stripe), het beste CMS (Contentful), de beste PIM (Akeneo).

De vier MACH-dimensies in detail

Microservices: ontleding voor begrensde context

In een MACH-architectuur wordt het commerciële domein opgesplitst in op elkaar afgestemde onafhankelijke diensten ai begrensde context van domeingestuurd ontwerp: 

// 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 vóór implementatie

In een API-first-systeem is de API het contract dat is gedefinieerd Voor van de implementatie. Elk team kan dankzij het contract zelfstandig zijn eigen dienst ontwikkelen API is al gedefinieerd. 

// 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: elastische schaling en beheerde services

Cloud-native betekent niet dat het in de cloud draait; het betekent dat het specifiek is ontworpen om te exploiteren cloudmogelijkheden: automatische horizontale schaling, fouttolerantie, waarneembaarheid geïntegreerd:

  • Docker-containers georkestreerd door Kubernetes (of Lambda Functions voor gebeurtenisgestuurde ladingen)
  • Beheerde databases (Cloud Spanner, RDS, DynamoDB) in plaats van zelfbeheerde instanties
  • Eventbus beheerd (AWS EventBridge, Google Pub/Sub) voor asynchrone communicatie
  • Wereldwijd CDN voor frontend-levering
  • Automatische stroomonderbreker en opnieuw proberen voor veerkracht

Headless: frontend vrij van backend

De H-dimensie van MACH is al onderzocht in het eerste artikel van de serie: de frontend verbruikt API, deze wordt niet gegenereerd door de backend. In een MACH-architectuur wordt dit voltooid betekent vaak a BFF (backend voor frontend) om de API te optimaliseren voor i specifieke klanten: 

// 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 versus Monolith: de echte vergelijking

MACH versus Monolith: wanneer het beter is, wat

  • Monolith beheerd (Shopify, WooCommerce): time-to-market in weken, klein team, lage kosten — ideaal voor GMV < 5 miljoen EUR/jaar
  • Gedeeltelijke MACH (zonder hoofd + best-of-breed): geleidelijke flexibiliteit, middelgroot team — ideaal voor GMV 5-50 miljoen EUR/jaar met specifieke behoeften
  • Volledige MACH: maximale flexibiliteit, hoge kosten, groot team - gerechtvaardigd voor GMV > 50 miljoen EUR/jaar of specifieke bedrijfsvereisten

MACH-governance en antipatroon

De meest voorkomende fout bij MACH-implementaties is te veel fragmenteren zonder governance:

MACH Antipatroon om te vermijden

  • Voortijdige microservices: Ontbinden in 20 services bij verwerking van 1000 bestellingen/maand is pure over-engineering. Begin met een modulaire monoliet, ontbind gewoon de delen die anders schalen.
  • Geen API-contracten met versiebeheer: Zonder API-versiebeheer, elk team zal anderen breken tijdens hun inzet. Gebruik OpenAPI 3.1 + semantisch versiebeheer.
  • Gecascadeerde synchrone oproepen: een verzoek dat 5 services achter elkaar aanroept latentie accumuleren. Gebruik waar mogelijk parallelle oproepen, CQRS-patroon voor zware leesbewerkingen.
  • Gedeelde database: Als twee MACH-services de database delen, is dat niet het geval echt onafhankelijk. Elke service moet een eigen datastore hebben.

Implementeer MACH stapsgewijs

U hoeft niet in één keer naar MACH te migreren. De wurger-vijgenpatroonbenadering het wordt aanbevolen:

  1. Fase 1: Voeg een koploze laag toe bovenop de bestaande monoliet. De voorkant nieuwe aanroepen API, de monoliet genereert de API via de REST/GraphQL-laag. Geen wijzigingen in de kern.
  2. Fase 2: Haal de eerste microservice op voor de functie met de meeste behoeften specificaties (vaak: zoeken of inventariseren). De monoliet blijft de rest verzorgen.
  3. Fase 3: Ga service voor service verder met het verwijderen en verwijder geleidelijk de afhankelijkheid van de monoliet.

Conclusies

MACH is een architecturale ambitie, geen checklist. De API-first en headless-principes ze bieden echte waarde, zelfs bij gedeeltelijke implementaties. De ontleding in microservices en de cloud-native maakt het plaatje compleet, maar vereist volwassenheid van de organisatie.

In de volgende artikelen verkennen we de concrete implementaties: Shopify Waterstof voor wie wil zonder hoofd op beheerde infrastructuur, Medusa.js voor degenen die de voorkeur geven aan zelf-gehoste open-source, bijv Saleor voor Python-teams met native GraphQL-behoeften.

Vorig artikel ← Headless Commerce: wat is het
Volgende in de serie Shopify Waterstof en zuurstof →