Der E-Commerce hat sich von Grund auf verändert. Die monolithische Architektur, die alles in einer einzigen Plattform bündelte, hat dem Headless Commerce Platz gemacht und, einen Schritt weiter, dem Composable Commerce. Wenn dein Shop dich zu bremsen beginnt (langsame Deploys, fragile Integrationen, eine Performance, die sich nicht erholt), ist das meist das erste Anzeichen.
Bei Kiwop haben wir mehr als 80 E-Commerce-Projekte umgesetzt, mit einer Kundenbindungsrate von 92 %. Diese Erfahrung hat uns gelehrt, wann ein Monolith sich nicht mehr lohnt, wann Headless den Unterschied macht und wann es besser ist, noch nicht zu migrieren.
Was ist Headless Commerce?
Headless Commerce trennt die Frontend-Schicht (die Oberfläche, die deine Kundschaft sieht) von der Backend-Schicht (die Geschäftslogik und die Daten). Frontend und Backend arbeiten unabhängig und kommunizieren über APIs.
Anders als beim klassischen Modell, wo alles in einer einzigen Plattform steckt, kannst du mit Headless mehrere Oberflächen (Web, mobile App, Kioske, IoT-Geräte) an ein einziges Backend anbinden. Jede Experience wird einzeln gestaltet und passt sich schneller an neue Technologien und an den Markt an.
Headless vs. Composable Commerce: der entscheidende Unterschied
Sie werden verwechselt, sind aber nicht dasselbe, und die Unterscheidung bestimmt deine Architektur.
Headless entkoppelt das Frontend vom Backend. Es ist eine Veränderung auf der Präsentationsebene: dahinter kann durchaus ein monolithisches Backend bleiben.
Composable geht weiter. Jede Backend-Komponente (Katalog, Checkout, Suche, Auftragsverwaltung) ist ebenfalls unabhängig und austauschbar, als beste verfügbare Lösung gewählt (best of breed) und über APIs verbunden. Headless ist tatsächlich eine der vier Säulen der MACH-Architektur, auf der Composable ruht.
In der Praxis ist die Grenze verschwommen: fast jedes Composable-Projekt ist headless, und viele Headless-Projekte setzen ihr Backend am Ende Stück für Stück zusammen. Deshalb behandelt dieser Guide beides.
Vorteile von Headless Commerce
- Grenzenlose User Experience: maßgeschneiderte Oberflächen für jedes Gerät und jeden Kanal, ohne die Einschränkungen einer integrierten Plattform.
- Skalierbarkeit und Agilität: du skalierst oder änderst einzelne Teile, ohne den Rest des Systems anzufassen.
- Performance: durch die Entkopplung des Frontends optimierst du die Ladezeit mit SSR/SSG und senkst die Absprungrate.
- Fortgeschrittene Personalisierung: du passt die Experience an jede Person an, was Conversion und Bindung steigert.
- Schnellere Innovation: du integrierst neue Technologien und Kanäle, ohne zu warten, bis die Plattform sie unterstützt.
- Sicherheit: getrennte Schichten verkleinern die Angriffsfläche für kritische Daten.
MACH-Architektur: die vier Säulen des Composable Commerce
MACH ist kein Produkt, sondern eine Reihe von Prinzipien:
- Microservices: jede Funktion (Katalog, Bestand, Preise, Bestellungen) ist ein eigenständiger Service. Fällt einer aus oder muss skalieren, reißt er den Rest nicht mit.
- API-first: die gesamte Kommunikation läuft über gut dokumentierte APIs, sodass jedes Frontend (Web, App, Kiosk, IoT) dieselben Daten nutzt und ERP, CRM oder Marketing ohne doppelte Logik anbindet.
- Cloud-native: eine für die Cloud gedachte Infrastruktur, mit Autoscaling und Deployments ohne Downtime. An einem Black Friday skaliert der Checkout, während der Rest seine normale Last hält.
- Headless: das Frontend baust du mit der Technologie, die du willst (Astro, Next.js, Remix, native App), und beziehst die Daten über APIs.
Drei von vier zu erfüllen ist kein MACH, genauso wenig wie ein Auto ohne Räder ein Auto ist.
Monolith vs. Composable: 7 Anzeichen, dass dein Monolith dich bremst
Nicht jeder Shop braucht Composable. Für einen kleinen, stabilen Katalog ist ein gut konfigurierter Monolith weiterhin die effizienteste Option. Aber es gibt klare Anzeichen, dass du an die Grenze gestoßen bist:
- Die Time-to-Market für eine neue Funktion liegt über 8 Wochen.
- Die Performance verschlechtert sich mit jeder Erweiterung: LCP über 3 Sekunden und Core Web Vitals im roten Bereich.
- Du operierst in mehr als 3 Märkten mit unterschiedlichen steuerlichen, sprachlichen und logistischen Anforderungen.
- Dein Team verbringt mehr als 40 % seiner Zeit mit Wartung statt mit Innovation.
- Du musst über Kanäle verkaufen, die deine Plattform nicht nativ unterstützt (Marktplätze, Social Commerce, B2B2C).
- Die Integrationen mit ERP oder CRM sind fragil und brechen bei jedem Update.
- Die Gesamtbetriebskosten steigen Jahr für Jahr, ohne dass der funktionale Wert mitwächst.
Erkennst du drei oder mehr wieder, ist es Zeit, den Wechsel zu prüfen. Nicht auf einen Schlag: die schrittweise Migration gibt es, und sie funktioniert.
Beste Headless- und Composable-Plattformen
Das Ökosystem ist gereift und längst nicht mehr nur Enterprise-Terrain. Open-Source-Optionen haben Composable auch dem Mid-Market geöffnet.
- commercetools: die Enterprise-Referenz. Nativ API-first, multistore und multimarket. Ideal ab 50.000 SKUs und mehreren Ländern; sein GMV-basiertes Pricing fällt bei geringen Volumen ins Gewicht.
- Medusa (Open Source): Headless-Framework in Node.js, sehr erweiterbar und ohne Vendor-Lock-in. Multi-Region und Multi-Currency.
- Saleor (Open Source): Composable auf Basis von Python und GraphQL, mit starkem Backend-Panel und developer-freundlichem Ansatz.
- Shopify Hydrogen: der schnelle Weg zu Headless, wenn du schon auf Shopify bist, mit Shopify-Backend und einem Frontend in React/Remix. Wir arbeiten damit in der Shopify-Entwicklung und schlüsseln es in unserem technischen Guide zu Shopify Hydrogen auf.
- Adobe Commerce (Magento): unterstützt Headless über GraphQL und PWA Studio, stark bei komplexen Katalogen und anspruchsvoller Geschäftslogik. Bevor du den Sprung wagst, lies wann du NICHT auf Magento headless migrieren solltest; wir arbeiten damit in der Magento-Entwicklung.
- BigCommerce: hybrider Ansatz, SaaS-Backend mit offenen APIs. Eine gute B2B-Option (kundenspezifische Preislisten, wiederkehrende Bestellungen).
Fürs Frontend ist Next.js eine der besten Optionen für einen Headless-Shop. Es gibt keine universell beste Plattform: es gibt die, die am besten zu deinem Volumen, deinem Team und deinem Grad an Personalisierung passt.
Wie du migrierst: das Strangler-Fig-Muster
Die Migration von einem Monolithen zu Composable verlangt keinen Big Bang. Das Strangler-Fig-Muster erlaubt einen schrittweisen, kontrollierten Übergang:
- Identifiziere die Komponente mit der größten Reibung (meist Suche, Checkout oder Content-Management).
- Baue den neuen Service parallel auf, während der Monolith weiterläuft.
- Leite den Traffic schrittweise um (10 %, 25 %, 50 %, 100 %) über ein API-Gateway.
- Schalte die Monolith-Komponente erst ab, wenn die neue stabil läuft.
- Wiederhole mit der nächsten Komponente.
Aus unserer Erfahrung mit mehr als 80 Projekten haben schrittweise Migrationen eine deutlich höhere Erfolgsquote als komplette Relaunches. Der Schlüssel ist, die Wirkung jeder Phase zu messen, bevor du weitergehst.
Performance und SEO im Headless Commerce
Performance ist Ranking und ist Conversion. Die Headless-Architektur wirkt auf beide Seiten:
- LCP: mit SSR/SSG (Astro, Next.js) lieferst du HTML in unter 1 Sekunde aus. Unsere Projekte verzeichnen nach der Migration eine Performance-Verbesserung von +35 %.
- INP: ohne das schwere JavaScript des Monolithen verbessert sich die Interaktivität.
- CLS: Komponenten mit festen Maßen, keine Layout-Sprünge.
- Crawlability: SSR sorgt dafür, dass Google alles indexiert, ohne von JavaScript abzuhängen, mit sauberen URLs und strukturierten Daten ohne die Fesseln des Themes.
Wenn du diesen Weg ausreizen willst, analysieren wir in Composable Commerce deinen Fall und entwerfen die Architektur.
Häufige Fragen
Ist Composable Commerce dasselbe wie Headless?
Nein. Headless ist eine der vier Säulen von MACH: es entkoppelt das Frontend, aber das Backend kann weiter monolithisch sein. Composable geht weiter, weil auch jede Backend-Komponente unabhängig und austauschbar ist.
Was kostet die Migration zu Composable Commerce?
Das hängt vom Katalog, den Integrationen und den Märkten ab. Das Strangler-Fig-Muster verteilt die Investition auf Phasen mit messbarem ROI, und Open-Source-Optionen wie Medusa oder Saleor senken die Lizenzkosten.
Ist das nur etwas für große Unternehmen?
Nicht mehr. Open-Source-Plattformen haben den Zugang demokratisiert. Ein Shop mit 5.000 bis 10.000 SKUs und Präsenz in 2 oder 3 Märkten profitiert davon, ohne die Investition, die das vor fünf Jahren verlangte.
Was passiert mit meinem Katalog während der Migration?
Mit dem Strangler-Fig-Muster läuft der Monolith ganz normal weiter, während die neuen Komponenten entstehen. Es gibt keine Downtime und keinen Datenverlust.
Brauche ich ein internes Technik-Team?
Für den Alltag ist es ratsam, aber Umsetzung und Migration lassen sich an eine Agentur auslagern, die das Wissen schrittweise überträgt.
Welche Plattform soll ich wählen?
commercetools für Enterprise mit hohem Volumen, Medusa oder Saleor, wenn du Open Source und volle Kontrolle schätzt, Shopify Hydrogen, wenn du schon auf Shopify arbeitest, und Magento oder Adobe Commerce für komplexe Kataloge.
Fazit
Der Monolith hat ein Jahrzehnt lang seinen Dienst getan, aber Omnichannel, Personalisierung in Echtzeit und extreme Performance verlangen ein anderes Fundament. Headless und Composable sind keine Mode: sie sind die Antwort auf reale Probleme wie stundenlange Deploys, fragile Integrationen und Plattformen, die einschränken statt zu ermöglichen.
Wenn dein E-Commerce den Punkt erreicht hat, an dem das Geschäft der Plattform entwächst, sprechen wir und schauen, wie wir dir diese Grenzen nehmen.