92% der US-Brands betreiben heute modulare, API-getriebene Commerce-Systeme. Der Agilitäts-Gewinn ist real für die Teams, die Composable richtig machen: rund 35% schneller absorbiert ihre Architektur Veränderung. Der Haken ist die Lücke zwischen 92% und 35%. Viele Teams sind 2022 bis 2024 in Composable gewechselt und 2025 mit längeren Engineering-Backlogs aufgewacht, nicht mit kürzeren. Integrations-Glue hat den Velocity-Gewinn aufgefressen.

Die gute Nachricht: das ist kein Urteil über Composable. Es ist ein Urteil darüber, wie Teams komponiert haben. Quer durch unsere Customer-Onboardings trennen vier Engineering-Patterns verlässlich die Stacks, die schnell bleiben, von denen, die in Seams ertrinken.

Das hier ist ein Sebastian-Voice-Stück, also kommen die Patterns mit den Trade-offs, die sie kosten.

Warum die Korrektur jetzt kommt

Drei Druckpunkte haben sich 2025 verdichtet:

1. Die Vendor-Zahl ist der Integrations-Kapazität davongelaufen. Ein typischer modularer Commerce-Stack spannt heute Backend, CMS, Search, Personalization, PIM, OMS, Payment-Orchestrierung und ein, zwei AI-Services. Acht bis zwölf Vendors sind keine Ausnahme. Jeder shippt Breaking-Changes auf eigener Cadence.
2. Das Frontend ist der Integrations-Steuereintreiber geworden. Backends wurden sauberer. Frontends haben jeden Seam absorbiert: Daten-Shape-Mismatches, Auth-Flows, Race-Conditions bei der Hydration, Preview-vs-Live-State, Locale-Handling. Das, was der Customer anfasst, wurde zum Koordinations-Punkt jedes Teams.
3. Das Editor-Versprechen hat sich abgenutzt. Marketern wurde Composable mit „mehr Flexibilität im Editor" verkauft. Bekommen haben sie vier Logins, drei Preview-Tools und einen Slack-Thread über die Frage, welches davon für eine Page kanonisch ist.

Gegen all das kann man mit Disziplin arbeiten. Die vier Patterns unten sind die Disziplin.

Pattern 1: Stack-Boundary-Contracts als Code

Jeder Seam zwischen zwei Services ist ein Contract. Die billigste Variante davon ist „der Consumer liest, was der Producer heute zufällig shippt". Die teure Variante heißt Schema-by-Prayer. Du zahlst beim dritten Breaking-Change dafür.

Was funktioniert:

• Jede Cross-Service-Shape als versioniertes Schema behandeln. GraphQL, JSON Schema oder Zod-typisierte Runtime-Validation. Eines davon picken und auf jeden Boundary anwenden, auch die langweiligen (Banner-Copy, Footer-Links, Redirect-Rules).
• Pro Consumer einen Contract-Test publizieren. Wenn das CMS ein Feld ändert, bricht der Contract-Test im Frontend, bevor der Storefront bricht. Behandle den Test wie ein CI-Gate, nicht wie ein Nice-to-Have.
• Version-Mismatches kommen als Warnung, nicht als 500. Ein Consumer muss eine neuere Producer-Shape lesen können und sauber fallback-en. Der Storefront serviert nie eine leere Seite, nur weil das CMS ein zusätzliches optionales Attribut shippt.

Trade-off: mehr Vorab-Schema-Arbeit. Teams, die diesen Schritt überspringen, schreiben im dritten Quartal die meisten Postmortems.

Pattern 2: Eine Orchestrierungs-Schicht, die die Seams besitzt

Das ist die häufigste Lücke. Teams wählen Best-of-Breed pro Domäne und bitten dann das Daten-Layer im Storefront, alles zur Request-Zeit zu verkleben. Der Storefront wird zur Default-Orchestrierungs-Schicht, ohne dass das jemand bewusst entworfen hat.

Was funktioniert:

• Die Orchestrierungs-Schicht benennen. Sie ist ein eigenes Deployable, kein Folder innerhalb der Next.js- oder Nuxt-App. Die Orchestrierungs-Schicht normalisiert Shapes, fanned Fetches aus, hält Caching-Strategie pro Ressourcen-Typ und exposes eine saubere API an die Rendering-Schicht.
• Cross-Cutting-Concerns aus dem Frontend rausziehen. Personalization-Entscheidungen, A/B-Branching, Locale-Resolution, Currency-Rounding. Wenn zwei Services sich auf eine Antwort einigen müssen, besitzt die Orchestrierungs-Schicht die Einigung.
• Die Rendering-Schicht darf langweilig bleiben. Der Vue- oder React-Tree macht Layout und Interaktion, nicht Variant-Resolution.

Das ist das Pattern, um das wir unsere Orchestr-Schicht gebaut haben. Teams, die es überspringen, haben am Ende Senior-Engineers, die das weltgrößte Custom-GraphQL-Gateway warten, statt Features zu shippen.

Pattern 3: Observability, die dem User folgt, nicht dem Service

Composable-Observability scheitert, wenn jeder Vendor isoliert beobachtet wird. Das CMS-Dashboard sagt „CMS okay". Das Search-Dashboard sagt „Search okay". Der Customer sagt „die PDP ist auf Mobile in Frankreich kaputt", und du hast nichts.

Was funktioniert:

• Trace-IDs traversieren jeden Boundary. Eine einzige ID läuft vom Edge durch Orchestrierung in jeden Service-Call und zurück. Wenn etwas bricht, kannst du den ganzen Request replayen, nicht nur das Symptom.
• Golden-Signals an der User-facing-Oberfläche definieren. LCP, INP, Error-Rate auf Add-to-Cart, Conversion-Rate auf den Top-20-SKUs. Keine Service-internen SLOs, sondern User-facing-Outcomes.
• Alerts auf User-Signal, nicht auf Service-Signal verdrahten. Eine 200-Response von Search, die null Results zurückgegeben hat, ist immer noch eine kaputte Search-Session. Erkenn das.

Trade-off: eine echte Investition in Tracing-Infrastruktur. Teams, die das aufschieben, erfahren von Outages durch Customer-Support-Tickets, drei Tage zu spät.

Pattern 4: Eine Frontend-Management-Schicht, die Editor-Leakage verhindert

Das ist das Pattern, das den Loop mit dem Marketing-Team schließt. Ohne das Pattern fühlt sich der Rest der Disziplin für die Leute, die die Arbeit machen, immer noch teuer an.

Der Failure-Mode heißt Editor-Leakage: jeder Backend-Service zieht seine eigene Admin-UI in den Marketer-Alltag. Vier Logins, vier Preview-Tools, vier Versionen von „wie sieht die Live-Page gerade aus". Der Composable-Stack funktioniert technisch. Die Editor-Experience ist eine Steuer.

Was funktioniert:

• Eine Editor-Oberfläche pro Storefront. Der Marketer editiert Hero, Copy, Search-Ranking-Rules, Redirect-Rules, Personalization-Varianten und AI-Agent-Prompts an einem Ort. Service-Boundaries sind Implementation-Detail, kein UX-Seam.
• Preview ist composite, live und akkurat. Kein CMS-Preview, das lügt, was Search ranken wird. Kein Personalization-Tool-Preview, das den CMS-Draft-State ignoriert. Composite-Preview, das aus jedem Service den aktuellen Draft-State zieht.
• Publish ist atomar auf Storefront-Ebene. Wenn der Marketer eine Kampagne publisht, die CMS, Search-Rules und eine Personalization-Variante anfasst, committen alle drei zusammen oder keine. Ein gescheitertes Sub-Publish lässt den Storefront nicht im Half-State.

Diese Schicht nennen wir Frontend Management Platform. Sie ist kein CMS, kein Personalization-Tool, kein Search-Tuner. Sie ist der Ort, an dem die Editor-Experience sauber bleibt, während das Backend modular bleibt.

Was dir die Disziplin bringt

Teams, die alle vier Patterns fahren, treffen zwei Outcomes, die gut kombinieren:

• Backlog-Wachstum verlangsamt sich. Feature-Arbeit kehrt zurück auf Wochen, nicht auf Quartale. Die 35% Agilitäts-Lift, von denen die Analysten sprachen, zeigen sich in echter Sprint-Velocity.
• Der Editor ist keine Geisel mehr. Marketer hören auf, Slack-Threads mit „welches Tool nutze ich für das SE-Hero" zu öffnen. Sie öffnen ein Tool. Composable wird für sie unsichtbar, und genau das ist der Punkt.

Teams, die Patterns überspringen, bekommen ein oder zwei Benefits per Zufall und verlieren sie beim nächsten Vendor-Swap.

Was ihr in eurem Stack dieses Quartal messen solltet

Wenn ihr wissen wollt, ob euer Composable-Stack in den 35% oder im 92%-minus-35% liegt, drei Messungen:

1. Mean-Time von „Merchandiser fragt nach Kampagne" zu „Kampagne ist live". Wenn mehr als eine Arbeitswoche und die Kampagne keinen neuen Code braucht: Editor-Layer leckt.
2. Anzahl Services, die ein typischer einzelner Bug anfasst. Wenn „der PDP-Preis hat geflackert" vier Teams in einem War-Room braucht: Orchestrierungs-Schicht fehlt.
3. Anteil Incidents, deren Root-Cause ein Cross-Service-Contract-Mismatch war. Wenn über 20%: ihr habt keine Stack-Boundary-Contracts. Ihr habt Stack-Boundary-Hoffnung.

Keine der drei Messungen braucht einen Vendor. Sie brauchen ein Quartal ehrliche Messung.

Wo das Composable in 2026 lässt

Composable war immer die richtige architektonische Richtung. Die Korrektur ist kein Rückzug zum Monolithen. Sie ist die Erkenntnis, dass Best-of-Breed pro Domäne nur auszahlt, wenn die Seams mit derselben Rigor entwickelt werden wie die Services selbst.

Die vier Patterns sind die Engineering-Rigor. Die Frontend-Management-Schicht ist das, was das Marketing-Team aus dem Engineering-War-Room raushält. Composable plus Frontend-Management ist das, was wir bei Laioutr bauen, weil wir zu viele Teams die Integrations-Steuer zahlen sahen und entschieden haben, dass diese Steuer der falsche Posten ist.

Wenn ihr sehen wollt, wie die Orchestr-Schicht und der Laioutr-Editor auf einem realen Stack zusammenspielen, läuft die Composable-Headless-Frontend-Page das durch. Wer in den Agentic-Teil dieses Themas eintauchen will: die Agentic-Frontend-Management-Platform-Page hat die AI-Patterns.

Die Korrektur ist real. Der Fix ist Engineering, nicht Vendor-Wechsel.