Composable Commerce mit Medusa: Modularität als Strategie, nicht als Buzzword

"Composable" steht in fast jedem Pitch-Deck und meint dort meist nichts – ein Etikett für "modern", das den nächsten Vertrag rechtfertigen soll. Bei Medusa ist es keine Marketing-Vokabel, sondern die Bauweise des Systems: ein modularer Commerce-Kern, an den Sie Payment, PIM, ERP, Search und CMS über klare APIs andocken.

Der Unterschied ist nicht semantisch, sondern budgetrelevant. Wer Composable als Folie kauft, bekommt am Ende einen Monolithen mit REST-Fassade. Wer die Architektur versteht, kauft Austauschbarkeit – die Fähigkeit, einen einzelnen Baustein zu ersetzen, ohne das ganze System neu zu plattformisieren. Genau das ist der strategische Wert, und genau daran entscheidet sich, ob Composable Commerce mit Medusa eine Investition oder ein teurer Umweg wird.

Medusa ist in vier Schichten aufgebaut: API Routes auf Express-Basis, darunter Workflows, darunter Module, ganz unten der PostgreSQL Data Store. Diese Trennung ist nicht kosmetisch. Sie ist der Grund, warum sich Commerce- und Infrastructure-Bausteine unabhängig voneinander austauschen lassen – "you can replace any of the third-party services … to build your preferred commerce ecosystem", wie die Architektur-Dokumentation es formuliert.

Ein Modul ist bei Medusa "a reusable package of functionalities related to a single domain or integration". Entscheidend ist die Isolation: Ein Modul greift nicht direkt auf die Datenmodelle eines anderen zu. Das klingt nach Einschränkung, ist aber der Kern der Modularität – kein Baustein kann einen anderen heimlich verkoppeln, und deshalb lässt sich jeder einzeln ersetzen oder ersatzlos entfernen. Diese Isolation ist die technische Voraussetzung dafür, dass "austauschbar" nicht nur im Vertragstext steht.

Verbunden werden die Module über Module Links. Statt Fremdschlüssel-Constraints quer durch die Datenbank zu ziehen, erzeugt Medusa eine automatische Link-Tabelle, die nur IDs speichert – keine harte Kopplung zwischen den Domänen. Darüber liegen die Workflows: Serien von Steps mit eingebauter durable execution und Rollback pro Step. Wenn eine Bestellung ein ERP-System, einen Payment-Provider und ein CMS berührt und der dritte Schritt fehlschlägt, kompensiert der Workflow die ersten beiden sauber zurück. Das ist die unspektakuläre, aber betriebsentscheidende Antwort auf die Frage, wie man Datenkonsistenz über Systemgrenzen hinweg hält.

Der Verkaufsvorteil von Composability ist selten "wir können alles bauen" – das können Sie mit einem Monolithen und genug technischer Schuld auch. Der Vorteil ist, dass Sie eine Fehlentscheidung wieder korrigieren können, ohne das ganze Haus abzureißen.

Konkret: Medusa liefert rund zwei Dutzend Commerce-Module out of the box – von Cart, Order, Payment und Pricing über Inventory und Fulfillment bis Promotion und Tax. Daneben stehen austauschbare Integrationen für Payment (Stripe, PayPal), Search (Algolia, Meilisearch) sowie CMS und ERP als eigene Module. Wenn Ihr Suchanbieter in zwei Jahren nicht mehr überzeugt, tauschen Sie das Search-Modul – nicht die Plattform. Das ist Best-of-Breed in der Praxis: pro Domäne das beste Werkzeug, verbunden über eine dokumentierte Commerce API, statt einer All-in-One-Suite, deren schwächstes Feature Sie mitschleppen, weil es eben dazugehört.

Das ist auch der Punkt, an dem ERP PIM Integration von einem Integrationsprojekt zu einer Architekturentscheidung wird. Ein PIM als eigenes Modul, ein ERP-Adapter als eigenes Modul, verbunden über Module Links und Workflows – das ist strukturell dasselbe Muster wie die interne Cart-Order-Verknüpfung, nur mit externen Systemen. Für Entscheider, die Legacy-Bestände anbinden müssen, ist genau das interessant: Medusa taugt als Integrationsschicht, die alte Systeme kapselt, statt sie abzulösen.

Hier wird die Architektur konkret prüfbar. Der Medusa-Core enthält kein Company-, Quote- oder Approval-Modul – die B2B-Grundlogik ist bewusst nicht Teil des Kerns. Was existiert, steckt im B2B-Starter: Company-/Employee-Management, per-Mitarbeiter-Spending-Limits mit konfigurierbaren Reset-Frequenzen, einfache Approval-Workflows auf Company-Ebene und Quote-Management mit Verhandlung.

Und jetzt der Punkt, der die These trägt: Diese Features sind im Starter als Custom Module (company, quote, approval) implementiert – nicht aus dem Core bezogen, nicht als SaaS-Feature-Flag geliefert. Der B2B-Starter beschreibt sich selbst als "designed to be customized and extended". Er ist Boilerplate zum Forken und Selbstpflegen, kein von Medusa gewartetes Produktfeature. Diese Unterscheidung ist keine Spitzfindigkeit, sondern eine Make-or-Buy-Frage mit direkter TCO-Konsequenz: Sie übernehmen Wartung und Weiterentwicklung dieses Codes.

Der eigentliche Beleg für die Composability-These ist aber, *wie* diese Module gebaut sind: als eigenständige Domänen, die über Module Links an Cart und Order hängen. Ein echter Procurement-Layer – mit Punchout-Katalogen, cXML und OCI, Kostenstellen, mehrstufigen Approval-Chains und Net-Terms-Invoicing – fehlt im Starter nachweislich und muss gebaut werden. Aber er hängt sich in dieselbe Struktur ein: als weiteres Modul, verbunden über dieselben Mechanismen. Nichts an der Architektur muss dafür aufgebrochen werden. Wer wissen will, was der Starter liefert und was Enterprise-Procurement wirklich verlangt, findet die ehrliche Abgrenzung in unserem Artikel dazu, dass Medusa kein schlüsselfertiges Procurement mitbringt. Und wer die Grundlagen sucht, warum Medusa überhaupt so aufgebaut ist, sollte mit Was ist Medusa.js? beginnen.

MACH steht für Microservices-based, API-first, Cloud-native und Headless; die MACH Alliance wurde im Juni 2020 gegründet und ergänzt das Akronym inzwischen um die Ebene "Open, Composable, Connected". Medusa folgt diesen Prinzipien in der eigenen Struktur: API-first über eine dokumentierte Schnittstelle, austauschbare Commerce- und Infrastructure-Module, und die explizite Einladung, Drittanbieter zu ersetzen. Die MACH-Architektur ist damit kein Label, das man aufklebt, sondern eine Bauentscheidung, die man an der Modul-Isolation ablesen kann.

An dieser Stelle ist Nüchternheit angebracht. Die MACH Alliance ist eine Interessenvertretung und nennt naturgemäß die Vorteile von Composability. Die Kehrseite – höhere Integrations-, Governance- und Betriebskomplexität, keine Out-of-the-box-Suite – steht dort nicht. Wer eine Architektur allein aus dem Marketing ihrer Fürsprecher bewertet, kauft die halbe Wahrheit. Composability ist ein Werkzeug mit klaren Kosten, kein Naturgesetz des Fortschritts.

Composable hat einen Rechnungsbetrag, und der steht nicht im Pitch-Deck. Mehr Module heißt mehr Integrationsarbeit, mehr bewegliche Teile, mehr Betrieb als bei einer All-in-One-Plattform. Der Produktiv-Stack von Medusa braucht zwingend PostgreSQL und Redis, muss in zwei Modi laufen (Server für API/Admin, Worker für Background-Jobs), verlangt mindestens 2 GB RAM und Node-20-Kompetenz im Team – plus eigenes Uptime-, Scaling- und Security-Patching.

Für einen einfachen, standardisierten B2C-Katalog ist das deutlich überdimensioniert. Eine saubere Erstimplementierung eines self-hosted Stacks liegt je nach Umfang erfahrungsgemäß im niedrigen bis mittleren fünfstelligen Bereich, der laufende Betrieb bei wenigen Stunden im Monat. Das ist gut investiert, wenn Sie mehrere Best-of-Breed-Systeme integrieren und Bausteine unabhängig austauschen wollen. Es ist verschwendet, wenn ein Managed-Shop dieselbe Anforderung mit einem Bruchteil des Betriebsaufwands erfüllt. Modularität rechnet sich erst, wenn Sie sie tatsächlich nutzen – nicht, weil sie modern klingt.

Der unbequeme Punkt: Composability kippt regelmäßig in ihr Gegenteil. Jeder Baustein bekommt einen eigenen Vendor, einen eigenen Vertrag, einen eigenen Betrieb, ein eigenes SLA und einen eigenen Ansprechpartner, der im Störfall auf die anderen zeigt. Aus "Best-of-Breed" wird ein Zoo aus Schnittstellen, in dem niemand mehr die Verantwortung für das Gesamtverhalten trägt.

Ohne klare Governance entsteht ein Integrations-Monster, das teurer ist als der Monolith, den es ablösen sollte – nur mit mehr Rechnungen und mehr Vendor Risk. Ich habe Setups gesehen, in denen fünf "beste" Einzelsysteme zusammen schlechter funktionierten als eine mittelmäßige Suite, weil die Integrationsschicht selbst zum ungepflegten Legacy-System wurde. Composability ohne Betriebsmodell ist kein Fortschritt, sondern verteilte technische Schuld.

Die Grenze verläuft nicht an der Technik, sondern an der Organisation. Wer die Datenmodellierung über Systemgrenzen hinweg nicht im Griff hat – etwa die Frage, wo Produktdaten führend gepflegt werden und wie sie mit dem Shop synchron bleiben – produziert mit Modulen dieselben Inkonsistenzen wie mit einem Monolithen, nur schwerer nachvollziehbar.

Behandeln Sie "Composable" nicht als Ziel, sondern als Mittel. Die richtige Frage ist nie "sind wir composable genug", sondern "welchen konkreten Baustein müssen wir in drei Jahren austauschen können, ohne neu zu plattformisieren". Wenn Sie diese Frage beantworten können, ist Medusa mit seiner Modul-Architektur ein präzises Werkzeug – und ein Procurement-Layer, ein neues PIM oder ein ERP-Wechsel bleiben eine Modul-Frage, keine Replatforming-Frage.

Wenn Sie die Frage nicht beantworten können, kaufen Sie mit jedem zusätzlichen Modul Optionalität, die Sie nie einlösen, aber jeden Monat betreiben. Dann ist der Monolith die ehrlichere Wahl. Die Entscheidung für oder gegen Composability ist keine Technologie-Präferenz, sondern eine Wette auf die eigene Änderungshäufigkeit – und die sollten Sie nüchtern einschätzen, bevor ein Anbieter sie für Sie einschätzt. Wer tiefer in Medusas Rolle im gesamten Commerce-Stack einsteigen will, findet den Überblick auf unserer Medusa-Themenseite.