Ce este MACH și cine l-a definit

MACH este un acronim inventat de Alianța MACH, o asociație de furnizori de tehnologie fondați în 2020 de commercetools, Contentful, EPAM Systems și alții. Nu este un produs — este un set de principii arhitecturale pentru sistemele de construcție întreprindere modernă.

  • M — Microservicii: fiecare funcție de business este un serviciu independent
  • A — API-first: fiecare serviciu expune API-uri bine definite ca interfață principală
  • C — Cloud-native: Creat pentru cloud public, cu scalare elastică și servicii gestionate
  • H — Headless: frontend și backend sunt decuplate

Ideea fundamentală este cel mai bun din rasă: în loc să cumpere o singură suită care face totul (mediocru), alege cel mai bun serviciu pentru fiecare funcție și compune o platformă pe măsură. Cel mai bun motor de căutare pentru produse (Algolia), cea mai bună casă (Stripe), cel mai bun CMS (conținut), cel mai bun PIM (Akeneo).

Cele patru dimensiuni MACH în detaliu

Microservicii: descompunere pentru context delimitat

Într-o arhitectură MACH, domeniul comercial este descompus în servicii independente aliniate ai context mărginit de design bazat pe domeniu: 

// 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 înainte de implementare

Într-un sistem API-first, API-ul este contractul care este definit Înainte de implementare. Fiecare echipă își poate dezvolta propriul serviciu în mod independent datorită contractului API-ul este deja definit. 

// 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 și servicii gestionate

Cloud-native nu înseamnă „rulează pe cloud” – înseamnă conceput special pentru a exploata capabilități cloud: scalare orizontală automată, toleranță la erori, observabilitate integrat:

  • Containere Docker orchestrate de Kubernetes (sau Funcții Lambda pentru încărcări bazate pe evenimente)
  • Baze de date gestionate (Cloud Spanner, RDS, DynamoDB) în loc de instanțe autogestionate
  • Autobuz de evenimente gestionat (AWS EventBridge, Google Pub/Sub) pentru comunicare asincronă
  • CDN global pentru livrare frontend
  • Întrerupător automat și reîncercați pentru rezistență

Headless: Frontend Free de la Backend

Dimensiunea H a lui MACH a fost deja explorată în primul articol al seriei: the frontend consumă API, nu este generat de backend. Într-o arhitectură MACH completează acest lucru adesea înseamnă a BFF (Backend pentru Frontend) pentru a optimiza API-ul pentru i clienti specifici: 

// 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: comparația reală

MACH vs Monolith: Când e mai bine Ce

  • Gestionat Monolith (Shopify, WooCommerce): timp de comercializare în săptămâni, echipă mică, costuri reduse — ideal pentru GMV < 5 milioane EUR/an
  • MACH parțial (fără cap + cel mai bun din rase): flexibilitate graduala, echipa medie — ideal pentru GMV 5-50 M EUR/an cu nevoi specifice
  • MACH complet: flexibilitate maximă, costuri ridicate, echipă mare — justificat pentru GMV > 50 milioane EUR/an sau cerințe specifice ale întreprinderii

Guvernare MACH și anti-model

Cea mai frecventă greșeală în implementările MACH este fragmentarea prea mult fără guvernare:

MACH Anti-model de evitat

  • Microservicii premature: Descompuneți în 20 de servicii atunci când manipulați 1000 comenzi/lună este pură suprainginerie. Începeți cu un monolit modular, doar descompuneți părțile care se scalează diferit.
  • Fără contracte API cu versiuni: Fără versiunea API, fiecare echipă va sparge pe alții în desfășurare. Adoptă OpenAPI 3.1 + versiunea semantică.
  • Apeluri sincrone în cascadă: O solicitare care apelează 5 servicii în secvență acumulează latența. Utilizați apeluri paralele acolo unde este posibil, modelul CQRS pentru citiri grele.
  • Baza de date partajată: Dacă două servicii MACH partajează baza de date, acestea nu sunt cu adevărat independentă. Fiecare serviciu trebuie să aibă propriul depozit de date.

Implementați MACH în mod progresiv

Nu trebuie să migrați la MACH dintr-o dată. Abordarea modelului smochinului strangler se recomanda:

  1. Faza 1: Adăugați un strat fără cap deasupra monolitului existent. Interfața noile apeluri API, monolitul generează API-ul prin stratul REST/GraphQL. Fără modificări la bază.
  2. Faza 2: Trageți primul microserviciu pentru funcția cu cele mai multe nevoi specificații (adesea: căutare sau inventar). Monolitul continuă să se ocupe de restul.
  3. Faza 3: Continuați serviciul de extracție cu serviciu, îndepărtând treptat dependența de monolit.

Concluzii

MACH este o aspirație arhitecturală, nu o listă de verificare. Principiile API-first și headless ele aduc valoare reală chiar și în implementări parțiale. Descompunerea în microservicii și cloud-native completează imaginea, dar necesită maturitate organizațională.

În următoarele articole vom explora implementările concrete: Shopify Hydrogen pentru cei care doresc fără cap pe infrastructura gestionată, Medusa.js pentru cei care preferă sursă deschisă auto-găzduită, de ex Vânzare sau pentru echipe Python cu nevoi native GraphQL.

Articolul anterior ← Comerț fără cap: Ce este
Următorul în serie Shopify Hidrogen și oxigen →