MACH — architektura nowoczesnego e-commerce bez monolitu

Problem

Klasyczne platformy e-commerce — Magento, PrestaShop, SAP Hybris — są monolitami. Frontend, backend, logika biznesowa i warstwa danych są ze sobą sztywno spięte. To wygodne na starcie, ale boli w skali:

• zmiana jednej rzeczy grozi zepsuciem reszty,
• każdy nowy landing czeka na cykl wydawniczy backendu,
• skalujesz całą aplikację, nawet gdy obciążony jest tylko jeden moduł,
• migracja na nowszą wersję to wielomiesięczny projekt sam w sobie.

MACH to odpowiedź na te ograniczenia. Nie jest to produkt, który kupujesz — to zestaw zasad architektonicznych.

Cztery filary MACH

Skrót rozwija się jako Microservices, API-first, Cloud-native, Headless.

Microservices

Zamiast jednej aplikacji rozbijasz system na niezależnie wdrażalne usługi: katalog produktów, koszyk, zamówienia, płatności, magazyn. Każda robi jedną rzecz i może być skalowana, aktualizowana albo podmieniana bez ruszania reszty.

API-first

Każda funkcja i każdy kawałek danych są dostępne przez API (REST albo GraphQL). System integruje się z czymkolwiek, co ma API — dowolny CRM, PIM, ERP, OMS. Nie jesteś ograniczony do listy „pięciu wspieranych integracji".

Cloud-native

Pełne wykorzystanie chmury, nie tylko hosting. Auto-scaling pod szczyty ruchu (Black Friday, kampanie), redundancja, failover. W górę gdy trzeba, w dół gdy spada ruch.

Headless

Frontend całkowicie oddzielony od backendu. Storefront gada z backendem przez API. Zmieniasz wygląd sklepu albo dokładasz aplikację mobilną bez dotykania logiki commerce — ten sam backend zasila wiele kanałów.

Jak to złożyć w praktyce

W MACH nie ma jednej „platformy". Składasz sklep z klocków:

• silnik commerce — produkty, koszyk, zamówienia (np. Saleor, Medusa, Sylius),
• frontend — Next.js, Nuxt, Remix,
• CMS / treści — Contentful, Storyblok, Sanity,
• wyszukiwarka — Algolia, Meilisearch,
• płatności, podatki, PIM — osobne usługi przez API.

Przykładowy układ stacku:

[ Next.js storefront ]
        │  (GraphQL / REST)
        ▼
[ Saleor / Medusa ]  ──►  [ Algolia ]   (wyszukiwarka)
        │                  [ Stripe ]    (płatności)
        │                  [ Contentful ] (treści)
        ▼
[ PostgreSQL / chmura ]

Frontend odpytuje backend po API. Przykład zapytania do GraphQL-owego API (Saleor):

query {
  products(first: 10, channel: "default") {
    edges {
      node {
        name
        pricing { priceRange { start { gross { amount currency } } } }
      }
    }
  }
}

Platformy open-source, którymi zarządzasz sam

Jeśli zależy Ci na suwerenności i braku vendor lock-in, najmocniejsze projekty open-source:

Footprint hostingowy bywa różny — Medusa i Vendure to proces Node przeciwko PostgreSQL, Saleor dokłada jeszcze Pythona, Redis i workera Celery.

Czego nie doszacujesz

MACH daje elastyczność, ale ma swoją cenę — i to nie tylko w licencjach.

Najczęstsze błędy przy wdrożeniu:

• traktowanie MACH jak buzzwordu i pomijanie ciężkiej pracy — granic serwisów, kontraktów API, własności komponentów,
• przejście na mikroserwisy bez dyscypliny cloud-native (CI/CD, monitoring) → niestabilność,
• słaby projekt API, który odtwarza sztywne zależności → „rozproszony monolit",
• nadmierna customizacja na starcie zamiast składania komponentów i iteracji.

Co się dzieje pod spodem

MACH nie jest strategią „wszystko albo nic". Migracja zwykle idzie etapami — wzorcem strangler, gdzie stopniowo podmieniasz komponenty monolitu na usługi MACH, zamiast robić ryzykowny „big bang". Zaczynasz najczęściej od podmiany frontendu na headless, a backend monolitu zostaje, dopóki nie wytniesz go po kawałku.

Sens MACH leży nie w samym akronimie, tylko w tym, jak te cztery własności są zaimplementowane. Mikroserwisy schowane w multi-tenant SaaS, do którego nie masz dostępu, dają mniej niż modularny backend, który możesz realnie modyfikować. Dlatego przy wyborze patrz na model dostępu i licencję, nie na samą deklarację „jesteśmy MACH".