Headless allein reicht nicht: Warum Backend-Microservices ohne Frontend-Layer die alte Komplexität nur verschieben

Wenn du heute ein Headless-Projekt planst oder evaluierst, begegnest du einer bestimmten Erzählung: Brich den Monolithen auf. Trenne Frontend und Backend. Nutze Best-of-Breed-Dienste für Commerce, Search, Content. Und dann, logischerweise, so die Erzählung, bekommst du Agilität, Speed, Skalierbarkeit.

Diese Erzählung stimmt halb. Der Backend-Teil stimmt. Der Frontend-Teil nicht.

Kelly Goetsch beschreibt in Microservices for Modern Commerce (O'Reilly, 2016) das Ziel von True Omnichannel so: Ein einziges Backend-System pro Business-Capability, und darüber hinaus UIs, die "more or less disposable" sind. Neue User Interfaces, für neue Kanäle, neue Geräte, neue Kontexte, entstünden dann schnell auf Basis der fertigen APIs.

Diese "disposable UIs"-These ist der teuerste Irrtum, der aus diesem eBook mitgenommen wurde. Und er erklärt, warum so viele Headless-Projekte mehr Frontend-Code produzieren als die Monolithen, die sie ersetzen sollten.

Was Backend-Microservices wirklich lösen

Verstehen wir zunächst, was Headless tatsächlich löst, denn es ist real.

Goetsch hat recht, dass horizontale Kopplung im Monolith-Backend die Hauptbremse für Commerce-Entwicklung ist. Der klassische Shopware-6-Monolith oder das SAP-Commerce-Deployment bedeutet: Pricing, Inventory, Promotions, Cart-Logic und CMS leben im selben Deployment-Artifact. Eine Änderung an der Promotions-Engine braucht ein Full-Release. Eine neue Kategorie-Seite in CMS bedeutet Backend-Deployment-Koordination.

Headless löst das strukturell. Commercetools managed Pricing, Promotions und Cart unabhängig voneinander. Algolia ist ausschließlich für Search zuständig. Contentful oder Hygraph für Content. Jeder dieser Dienste hat seinen eigenen Deployment-Zyklus, sein eigenes Team, seine eigene Roadmap. Die Backend-Disaggregation funktioniert.

Goetsch beschreibt das als "systems of record for each bit of functionality (pricing, promotions, products, inventory, etc.)", und die Praxis 2026 gibt ihm vollständig recht. Kein seriöses Commerce-Unternehmen jenseits eines gewissen Volumens betreibt noch ein einziges Backend-System für alle diese Funktionen.

Was Backend-Microservices nicht lösen: der neue Frontend-Engpass

Hier liegt das Problem. Sobald das Backend aus Dutzenden von Microservices besteht, muss das Frontend diese Dienste koordinieren. Und diese Koordination ist nicht trivial.

Ein typischer Composable-Storefront muss Folgendes leisten:

Daten-Aggregation: Eine einzelne Produktseite benötigt Daten aus dem Produkt-Microservice (commercetools), dem Inventory-Service, dem Pricing-Service, dem Reviews-Service und dem CMS. Das ist mindestens fünf separate API-Calls, die koordiniert, gecacht und fehlerbehandelt werden müssen.

Caching-Strategie pro Datentyp: Produktbeschreibungen können aggressiv gecacht werden. Inventory muss bei Checkout-Entry frisch gelesen werden. Preise nach Promotion-Trigger sofort invalidiert. Diese Caching-Policy ist heute in den meisten Projekten verteilt über Page-Templates, Middleware-Layer und Edge-Functions, niemand hat sie als Ganzes designed.

Personalisierung near-Render: Wenn Personalisierung erst im Backend passiert, verlierst du Edge-Performance. Wenn sie im Frontend passiert, muss das Frontend die Personalisierungs-Logic tragen. Das ist kein kleines Thema.

A/B-Testing-Infrastruktur: Im Monolith hattest du ein einziges Deployment-Artifact, das du versionieren konntest. Im Composable-Storefront hast du Frontend-Code, der A/B-Varianten über mehrere Microservice-Calls spannt. Das braucht eigene Infrastruktur.

Multi-Markt-Deployment: DE, AT, CH, EN, jede Localisation mit eigenen Preisen, eigenem Content, eigenen Promotionen, eigener Navigation. Im Monolith war das alles in einem System. Im Composable-Stack musst du das über alle Layer koordinieren.

Performance-Budget-Management: Core Web Vitals sind ein Ranking-Faktor. Ein Composable-Storefront, der zehn API-Calls parallel feuert und deren Antworten rendered, hat ein strukturelles Performance-Problem, das der Monolith mit Server-Side-Rendering nie hatte.

All das ist echter Frontend-Aufwand. Und er ist nicht kleiner als der Backend-Aufwand des alten Monolithen. Er ist nur anders verteilt, und weil er im Frontend liegt, ist er weniger sichtbar in traditionellen Backend-fokussierten IT-Budgets.

Die "Disposable UI"-Illusion in der Praxis

Goetsch schreibt, dass neue UIs "in a few days" entstehen können, wenn die Backend-APIs vorhanden sind. Das ist in einer einfachen Demo-Umgebung wahr. In einer Produktionsumgebung mit realen Anforderungen ist es falsch.

Was wirklich passiert: Jeder neue Frontend-Touchpoint, Mobile App, Kiosk, internationaler Markt, neuer Kanal, erbt die gesamte Koordinations-Komplexität des Backend-Setups. Du baust nicht einfach eine neue UI auf fertigen APIs. Du baust eine neue UI, die:

• Caching-Policies für alle genutzten Microservices kennt und implementiert
• Personalisierungs-Logic für den Kontext des neuen Touchpoints enthält
• A/B-Testing-Infrastruktur mitbringt oder konsumiert
• Performance-Budgets für den neuen Kanal einhält
• Error-States und Circuit-Breaker-Logic für jeden API-Call enthält

Das ist kein paar Tage Arbeit. Das ist ein vollständiges Frontend-Projekt, jedes Mal.

Das Paradoxon: Je mehr Backend-Microservices du hast, desto größer ist die Coordination-Komplexität im Frontend. Die Backend-Disaggregation, die dich schneller machen sollte, macht dein Frontend langsamer.

Was "Outer Architecture für den Frontend-Layer" bedeutet

Goetsch beschreibt in Kapitel 4 die Outer Architecture von Microservices: die Schicht, die zwischen den Microservices sitzt und für Container Orchestration, Service Discovery, API Gateways und Eventing zuständig ist. Er schreibt: "Outer architecture is best handled by a single team that is composed of your best programmers."

Die Analogie für den Frontend-Layer ist direkt: Du brauchst eine Outer Architecture für den Frontend-Layer, eine Schicht, die die Koordination zwischen Backend-Microservices und Frontend-Rendering standardisiert, ohne dass jedes Page-Template diese Logik neu implementieren muss.

Das ist, was eine Frontend Management Platform (FMP) tut. Sie übernimmt:

• Composition Layer: Welche Datenquellen werden für welche Seite aggregiert? Definiert deklarativ, nicht in jedem Page-Template neu.
• Caching-Policy-Standard: Deklarative Caching-Rules pro Datentyp, statt verteilter Middleware-Logik.
• Deployment-Infrastruktur: Frontend-Deployments ohne Backend-Koordination, rollback-fähig, edge-deployed.
• Performance-Budget-Enforcement: Core Web Vitals als First-Class-Constraint, nicht als nachgelagertes Audit.
• Personalisierungs-Layer: Near-Render-Personalisierung ohne Custom-Middleware pro Touchpoint.

Das ist nicht ein weiteres CMS. Das ist die Container Orchestration für deinen Frontend-Layer.

Warum das für Shopware- und commercetools-Projekte besonders relevant ist

Die beiden häufigsten Headless-Migrationsszenarien 2026 sind:

Shopware-Headless: Shopware 6 bietet eine saubere API-Schicht. Viele Merchants migrieren Frontend-seitig auf Next.js oder Nuxt.js, behalten aber Shopware als Backend-System. Das Ergebnis: schnelles Backend, komplexes Custom-Frontend. Ohne Frontend-Layer-Standard entstehen pro Markt und pro Kanal eigene Frontend-Implementierungen.

commercetools-Stack: Der commercetools-Stack ist backend-seitig exzellent modular. Aber genau weil alles API-first ist, ist das Frontend die einzige Stelle, an der Komposition stattfindet. Ohne FMP landet diese Kompositions-Logik im Next.js-Projekt, und wächst unkontrolliert.

Ein Laioutr Headless Frontend für Shopware bzw. für commercetools adressiert genau diesen Gap: vorkonfigurierter Frontend-Layer, der die Kompositions- und Caching-Logic standardisiert, sodass du nicht für jedes Projekt neu anfängst.

TCO: Was ein Custom-Build wirklich kostet

Die häufigste Fehlkalkulation in Headless-Projekten ist der TCO-Vergleich. Frontend-Teams vergleichen oft die initiale Entwicklungszeit eines Custom-Frontend mit dem Licensing-Fee eines FMP, und der Custom-Build gewinnt auf den ersten Blick.

Was nicht eingerechnet wird:

• Laufende Maintenance des Custom-Kompositions-Layers (jede Backend-API-Änderung bricht irgendetwas)
• Performance-Optimierung (Core Web Vitals degradieren mit jeder neuen Feature-Addition)
• Developer-Onboarding (neuer Entwickler muss das proprietäre Kompositions-Framework verstehen)
• Multi-Markt-Expansion (jede neue Localisation skaliert den Custom-Build proportional)
• A/B-Testing-Infrastruktur (oft als separates Projekt nachgebaut)

Ein FMP-Modell hat höhere initiale Kosten, aber einen deutlich flacheren TCO-Verlauf über zwei bis drei Jahre, weil Kompositions-Logic, Caching und Deployment-Infrastruktur nicht neu gebaut werden.

Wenn dich diese Rechnung im Detail interessiert: Fordere einen TCO-Vergleich an.

Fazit: Headless braucht einen Frontend-Layer-Standard

Microservices for Modern Commerce hat den Commerce-Stack beschleunigt, aber die Backend-only-Fokussierung hat eine Generation von Headless-Projekten mit einem strukturellen Frontend-Problem zurückgelassen.

Das Problem ist lösbar. Aber es ist nur lösbar, wenn du den Frontend-Layer mit derselben architektonischen Ernsthaftigkeit behandelst wie den Backend-Layer. Das bedeutet: eigene Outer Architecture, eigene Caching-Standards, eigene Deployment-Infrastruktur, eigenes Ownership.

Ohne das wird Headless nicht schneller als der Monolith. Es wird nur teurer.

[Frontend-Layer als FMP, TCO-Vergleich anfordern](https://www.laioutr.com/demo)

Quelle: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.