Composable Commerce mit Magento: MACH-Architektur umsetzen

1. Was Composable Commerce für Magento bedeutet

Composable Commerce beschreibt einen architektonischen Ansatz, bei dem ein Shop nicht mehr als monolithische Einheit betrieben wird, sondern aus austauschbaren, spezialisierten Services zusammengesetzt ist. Statt Suche, Content-Management, Checkout und Frontend in einer einzigen Applikation zu bündeln, übernimmt jedes Teilsystem genau eine Aufgabe und kommuniziert über definierte APIs mit den anderen. Für Magento bedeutet das einen Rollenwechsel: von der Alles-Plattform zur spezialisierten Commerce-Engine, die Produktkatalog, Preislogik, Warenkorb und Checkout verantwortet, während andere Aufgaben an dedizierte Best-of-Breed-Services delegiert werden.

Diese Verschiebung ist kein rein theoretisches Konzept, sondern eine Reaktion auf reale Probleme monolithischer Architekturen: Ein einzelnes Deployment für Content-Änderungen und Commerce-Logik verlangsamt Release-Zyklen, ein einzelner Skalierungspunkt für alle Funktionen führt zu ineffizienter Ressourcennutzung, und ein einzelnes Frontend-Templating-System schränkt die Möglichkeiten für native Apps oder IoT-Vertriebskanäle ein. Composable Commerce mit Magento löst diese Probleme, indem jede Komponente unabhängig skaliert, deployt und ausgetauscht werden kann, solange die API-Verträge stabil bleiben.

2. Die MACH-Prinzipien im Detail

Das Akronym MACH fasst die vier Grundprinzipien zusammen, die eine echte Composable Commerce-Architektur ausmachen: Microservices, API-first, Cloud-native und Headless. Microservices bedeutet, dass jede fachliche Domäne (Produktkatalog, Preisfindung, Checkout, Kundenkonto) als eigenständiger, unabhängig deploybarer Dienst existiert, statt als eng gekoppeltes Modul innerhalb eines Monolithen. API-first heißt, dass jede Funktion zuerst als API entworfen wird, bevor überhaupt eine Benutzeroberfläche existiert, was Magento durch seine ausgereifte REST- und GraphQL-Schicht von Haus aus gut unterstützt.

Cloud-native bezieht sich auf die Fähigkeit, in containerisierten, horizontal skalierbaren Umgebungen zu laufen, ohne von einer festen Serverinstanz abhängig zu sein, ein Anspruch, den Magento über Docker- und Kubernetes-Setups grundsätzlich erfüllen kann, auch wenn der historische Monolith-Ursprung an manchen Stellen noch Anpassungsbedarf zeigt. Headless schließlich trennt die Präsentationsschicht vollständig von der Backend-Logik, sodass ein und dieselbe Magento-Instanz gleichzeitig eine Web-Storefront, eine native App und einen Voice-Commerce-Kanal bedienen kann, ohne dass die Backend-Logik dafür angepasst werden muss.

# Beispiel: Magento GraphQL-Query fuer eine Headless-Storefront
# Nur die Felder anfordern, die das jeweilige Frontend tatsaechlich braucht
query GetProductForStorefront($sku: String!) {
  products(filter: { sku: { eq: $sku } }) {
    items {
      id
      name
      sku
      price_range {
        minimum_price {
          regular_price { value currency }
          final_price { value currency }
        }
      }
      media_gallery {
        url
        label
      }
      __typename
    }
  }
}

3. Magento als Commerce-Engine im Composable Stack

In einer Composable Commerce-Architektur übernimmt Magento gezielt die Rolle der Commerce-Engine: Produktkatalogverwaltung, komplexe Preisregeln, Lagerbestandslogik über Multi-Source-Inventory, Warenkorb und Checkout-Orchestrierung. Diese Kernkompetenzen sind über Jahre gewachsen und lassen sich nur mit erheblichem Aufwand durch spezialisierte Nischenanbieter ersetzen, weshalb Magento in vielen Composable-Stacks bewusst als das stabile Rückgrat gewählt wird, während andere Komponenten flexibler ausgetauscht werden.

Wichtig ist dabei, die Grenzen dieser Rolle bewusst zu ziehen: Ein CMS für redaktionelle Inhalte, ein dedizierter Search-Service für Facettensuche und Relevanz-Ranking sowie ein Payment-Orchestrator für multiple Zahlungsanbieter sollten in einer echten Composable Commerce-Architektur nicht in Magento selbst implementiert werden, sondern als externe Services angebunden werden. Wer versucht, alle Zusatzfunktionen weiterhin monolithisch in Magento zu bauen, verliert den zentralen Vorteil der Composable-Architektur: unabhängige Skalierung und unabhängige Release-Zyklen pro Komponente.

<?php
declare(strict_types=1);

namespace Mironsoft\ComposableGateway\Model;

use Magento\Framework\Webapi\Rest\Request;
use Psr\Log\LoggerInterface;

/**
 * Publishes commerce-domain events to an external message bus
 * so downstream composable services (search, recommendations, CMS)
 * stay in sync without a direct database dependency on Magento.
 */
final class CommerceEventPublisher
{
    /**
     * @param LoggerInterface $logger Logs publish failures for observability.
     * @param EventBusClientInterface $eventBusClient Adapter to the external event bus.
     */
    public function __construct(
        private readonly LoggerInterface $logger,
        private readonly EventBusClientInterface $eventBusClient,
    ) {
    }

    /**
     * Publishes a product price change event to the composable stack.
     *
     * @param string $sku Product SKU affected by the price change.
     * @param float $newPrice The newly calculated final price.
     * @return void
     */
    public function publishPriceChanged(string $sku, float $newPrice): void
    {
        try {
            $this->eventBusClient->publish('commerce.product.price_changed', [
                'sku' => $sku,
                'price' => $newPrice,
                'timestamp' => (new \DateTimeImmutable())->format(DATE_ATOM),
            ]);
        } catch (\Throwable $exception) {
            $this->logger->error('Failed to publish price change event', [
                'sku' => $sku,
                'exception' => $exception->getMessage(),
            ]);
        }
    }
}

4. Die API-Schicht: REST vs. GraphQL

Die API-Schicht ist das verbindende Element jeder Composable Commerce-Architektur, und Magento bietet dafür sowohl eine REST- als auch eine GraphQL-Schnittstelle. GraphQL eignet sich besonders für Storefront-Anwendungen, weil ein Frontend genau die Felder anfordern kann, die für die jeweilige Ansicht benötigt werden, was Overfetching vermeidet und die Anzahl der Roundtrips reduziert. REST bleibt die bessere Wahl für administrative Integrationen, Batch-Operationen und Server-zu-Server-Kommunikation, bei denen klar definierte Ressourcen-Endpunkte und Standard-HTTP-Semantik wichtiger sind als Flexibilität in der Feldauswahl.

In der Praxis kombinieren gut aufgebaute Composable Commerce-Architekturen beide Ansätze bewusst: GraphQL für die Storefront-Kommunikation, REST für Backoffice-Integrationen wie ERP-Synchronisation oder Bestellexport. Ein häufiger Fehler ist, eine einzige API-Technologie für alle Anwendungsfälle erzwingen zu wollen, statt die jeweiligen Stärken von REST und GraphQL gezielt für den passenden Integrationstyp einzusetzen. Wichtig ist zudem, in beiden Fällen konsequent auf Rate-Limiting, Caching-Header und Versionierung zu achten, da mehrere unabhängige Frontends und Services gleichzeitig gegen dieselbe API arbeiten.

5. Frontend-Entkopplung: Headless-Optionen

Die Entkopplung des Frontends ist der sichtbarste Teil jeder Composable Commerce-Migration. Für Magento stehen dabei mehrere Wege offen: Adobes eigenes PWA Studio, das Open-Source-Projekt Vue Storefront, das direkt gegen die Magento GraphQL-API arbeitet, oder ein vollständig eigenentwickeltes Frontend mit einem beliebigen modernen Framework wie Next.js oder Nuxt. Jede dieser Optionen respektiert das Grundprinzip von Headless: Das Frontend kennt keine Magento-spezifischen Template-Strukturen, sondern konsumiert ausschließlich die API-Schicht.

Die Wahl zwischen diesen Optionen hängt stark vom vorhandenen Frontend-Team ab. Teams mit React-Erfahrung profitieren von PWA Studio oder einem eigenen Next.js-Aufbau, Teams mit Vue-Hintergrund von Vue Storefront. Wichtig für den Composable Commerce-Gedanken ist, dass das Frontend unabhängig vom Magento-Release-Zyklus deployt werden kann. Ein Content-Update im Frontend sollte kein Magento-Deployment erfordern, und umgekehrt sollte ein Backend-Update der Preislogik keinen Frontend-Neubau nötig machen, solange sich die API-Verträge nicht ändern.

{
  "api_gateway_routing": {
    "commerce_domain": {
      "target": "magento-graphql",
      "path_prefix": "/api/commerce",
      "cache_ttl_seconds": 60
    },
    "content_domain": {
      "target": "headless-cms",
      "path_prefix": "/api/content",
      "cache_ttl_seconds": 300
    },
    "search_domain": {
      "target": "dedicated-search-service",
      "path_prefix": "/api/search",
      "cache_ttl_seconds": 30
    }
  }
}

6. Drittsysteme als austauschbare Services integrieren

Der eigentliche Mehrwert von Composable Commerce zeigt sich, wenn Drittsysteme als klar abgegrenzte, austauschbare Services in die Architektur integriert werden, statt als tief verwobene Magento-Erweiterungen. Ein dedizierter Such-Service wie Algolia oder Elastic App Search kann parallel zur nativen Magento-Suche laufen und über die API-Schicht angebunden werden, ohne den Produktkatalog-Code in Magento selbst zu verändern. Ein Headless-CMS wie Contentful oder Storyblok übernimmt redaktionelle Inhalte, während Magento ausschließlich für transaktionale Commerce-Daten zuständig bleibt.

Bei Zahlungsanbietern zeigt sich das Prinzip besonders deutlich: Ein Payment-Orchestrator wie Spreedly oder eine eigene Payment-Abstraktionsschicht kann mehrere Zahlungsanbieter hinter einer einheitlichen Schnittstelle bündeln, sodass Magento nur einen einzigen Integrationspunkt braucht, während im Hintergrund PayPal, Klarna oder Adyen ausgetauscht werden können, ohne den Magento-Checkout-Code anzufassen. Diese Entkopplung reduziert das Risiko, dass ein einzelner Anbieterwechsel zu einem umfassenden Refactoring führt, ein Problem, das monolithische Zahlungsintegrationen häufig verursachen.

7. Event-Driven-Architektur zwischen den Services

Damit die einzelnen Services einer Composable Commerce-Architektur konsistent bleiben, ohne sich gegenseitig synchron aufzurufen, kommt in den meisten Setups eine Event-Driven-Architektur zum Einsatz. Magento publiziert Domain-Events wie Preisänderungen, Bestandsänderungen oder neue Bestellungen über einen Message Broker wie RabbitMQ oder Kafka, und andere Services abonnieren genau die Events, die sie benötigen. Ein Such-Service reagiert auf Produktänderungen mit einer Re-Indexierung, ein Empfehlungssystem auf neue Bestellungen mit aktualisierten Empfehlungsmodellen, ohne dass Magento diese nachgelagerten Systeme direkt kennen oder aufrufen muss.

Diese lose Kopplung über Events reduziert die Ausfallwahrscheinlichkeit erheblich: Fällt der Empfehlungsservice aus, bleibt der Checkout in Magento vollständig funktionsfähig, weil keine synchrone Abhängigkeit besteht. Der Preis dieser Robustheit ist erhöhte Komplexität bei der Nachvollziehbarkeit: Ein Fehler in einem nachgelagerten Service zeigt sich nicht sofort, sondern erst mit Verzögerung, und die Fehlersuche erfordert Tracing über mehrere Systeme hinweg. Ein durchdachtes Event-Schema mit klaren Versionierungsregeln ist deshalb Pflicht, sobald mehr als zwei oder drei Services an denselben Event-Stream angebunden sind.

# event-schema.yaml: Vertragsdefinition fuer ein Domain-Event
event: commerce.order.placed
version: "1.2"
schema:
  order_id: { type: string, required: true }
  customer_id: { type: string, required: false }
  items:
    type: array
    items:
      sku: { type: string, required: true }
      qty: { type: integer, required: true }
  total_amount: { type: number, required: true }
  currency: { type: string, required: true }
  placed_at: { type: string, format: date-time, required: true }

# Konsumenten dieses Events (zur Dokumentation, nicht technisch erzwungen)
consumers:
  - search-reindex-service
  - recommendation-engine
  - fulfillment-orchestrator

8. Herausforderungen: Konsistenz, Latenz, Betrieb

Trotz aller Vorteile bringt Composable Commerce reale Herausforderungen mit sich, die vor der Migration ehrlich adressiert werden müssen. Konsistenz ist die größte davon: Wenn Produktdaten in Magento, im Such-Index und im CMS parallel vorgehalten werden, entstehen zwangsläufig kurze Zeitfenster, in denen diese Systeme nicht synchron sind. Für die meisten E-Commerce-Anwendungsfälle ist diese Eventual Consistency akzeptabel, für preiskritische Anzeigen wie Rabattaktionen kann sie aber zu sichtbaren Inkonsistenzen führen, wenn die Event-Verarbeitung verzögert ist.

Latenz ist die zweite Herausforderung: Jeder zusätzliche Service in der Kette von Anfrage zu Antwort addiert Netzwerk-Overhead, und ein Composable-Stack mit fünf oder sechs beteiligten Services kann bei schlechtem Design langsamer werden als ein gut optimierter Monolith. Die dritte Herausforderung ist die Betriebskomplexität: Statt einer einzigen Magento-Instanz müssen nun mehrere unabhängige Services überwacht, gepatcht und skaliert werden, was ohne etablierte DevOps-Praxis und zentrales Observability-Tooling schnell unübersichtlich wird. Wer diese drei Herausforderungen unterschätzt, erlebt bei Composable Commerce oft eine höhere Betriebslast als erwartet.

9. Monolith vs. Composable im direkten Vergleich

Die folgende Tabelle stellt die zentralen Unterschiede zwischen einem klassischen Magento-Monolithen und einer Composable Commerce-Architektur gegenüber, als Entscheidungsgrundlage für die eigene Roadmap.

Die Tabelle macht deutlich, dass Composable Commerce kein pauschaler Fortschritt gegenüber dem Monolithen ist, sondern ein bewusster Tausch von Einfachheit gegen Flexibilität. Für Shops mit klarem Multi-Channel-Bedarf und etablierter DevOps-Praxis überwiegen die Vorteile deutlich, für kleinere Teams ohne diese Voraussetzungen kann ein gut strukturierter Monolith die pragmatischere Wahl bleiben.

10. Zusammenfassung

Composable Commerce mit Magento verändert die Rolle der Plattform grundlegend: von der Alles-Lösung zur spezialisierten Commerce-Engine innerhalb eines Netzwerks austauschbarer Services. Die MACH-Prinzipien Microservices, API-first, Cloud-native und Headless bilden das architektonische Fundament, während REST und GraphQL als API-Schicht die Kommunikation zwischen den Services ermöglichen. Event-Driven-Architektur hält die einzelnen Bausteine lose gekoppelt und robust gegen Teilausfälle.

Der Umstieg auf Composable Commerce ist kein automatischer Fortschritt, sondern ein bewusster Tausch: mehr Flexibilität und unabhängige Release-Zyklen gegen höhere Betriebskomplexität und Eventual Consistency. Wer diese Kompromisse versteht und die Grenzen zwischen Magento als Commerce-Engine und den umliegenden Services sauber zieht, gewinnt eine Architektur, die mit dem Geschäft mitwächst, statt bei jedem neuen Vertriebskanal an ihre Grenzen zu stoßen.

11. FAQ: Composable Commerce mit Magento