Composable Commerce: Bausteine, Integration und Betriebsrisiken
Kurz gesagt
Ein zusammengesetzter Shop besteht aus mehreren getrennten Diensten, die über Programmierschnittstellen zusammenarbeiten; der hier beschriebene Aufbau trennt Storefront, Katalog, Suche, Warenkorb, Zahlung und Bestellabwicklung, während die MACH-Prinzipien nur unabhängig bereitstellbare, austauschbare Fähigkeiten verlangen, nicht diese Aufteilung. Jede Schnittstelle ist ein eigener Fehlerpunkt; deshalb gehören Ausfallverhalten, Zuständigkeiten und der Ausstieg vor der Entscheidung in den Vertrag. Die technische Sicht ist in Deutschland, Österreich und der Schweiz gleich.
Das Wichtigste
- In dem hier beschriebenen Aufbau laufen Katalog, Suche, Warenkorb, Zahlung und Bestellabwicklung als getrennte Dienste mit eigenen Daten; die MACH-Prinzipien fordern unabhängig bereitstellbare, austauschbare Fähigkeiten, nicht diese Aufteilung.
- MACH heißt microservices-based, API-first, cloud-native SaaS und headless; so beschreibt es das Manifest der MACH Alliance.
- RFC 9110 zählt POST nicht zu den idempotenten Methoden; ein wiederholter POST-Aufruf ohne Kennung kann eine Bestellung doppelt anlegen (Abschnitt 9.2.2).
- Sechs Stationen zu je 99,9 Prozent ergeben bei unabhängig angenommener Verfügbarkeit und einer Bestellung, die alle sechs Stationen braucht, rechnerisch rund 99,4 Prozent Verfügbarkeit (Beispielrechnung).
- Fünf Aufrufe mit je zwei Sekunden Zeitlimit ergeben bis zu zehn Sekunden Wartezeit (Beispielrechnung).
- Für Cloud-Dienste verlangt der BSI-Grundschutz dokumentierte Schnittstellen und Verantwortlichkeiten (Baustein OPS.2.2, Anforderung A4).
Bei einem zusammengesetzten Shop entscheidet nicht die Funktionsliste, sondern das Verhalten an den Übergängen: Wer antwortet, wie lange darf es dauern, und was passiert, wenn die Antwort ausbleibt. Dieser Artikel zeigt die Bausteine einer solchen Kette, ihre Wege und die Folgen eines Ausfalls je Baustein.
Was einen zusammengesetzten Shop ausmacht
Trennen Sie Katalog, Suche, Warenkorb und Abwicklung in mehrere Dienste, entsteht zwischen je zwei Teilen ein Vertrag: ein Format, ein Zeitlimit und eine Zuständigkeit. Führt jeder Dienst seine eigenen Daten und wird unabhängig von den anderen aktualisiert, kann er einzeln ausfallen. Ein Monolith bündelt dieselben Funktionen in einer Anwendung, die Sie über Erweiterungen ausbauen; die Kosten beider Wege über drei Jahre vergleicht der Artikel Monolith oder Headless.
Der Begriff MACH stammt von der MACH Alliance, einem Zusammenschluss von Anbietern, Integratoren und Enablern. Ihr Manifest beschreibt MACH als microservices-based, API-first, cloud-native SaaS und headless; die Prinzipienseite der Allianz fasst das in der Fassung von 2026 unter offen, zusammensetzbar und verbunden zusammen: Jede Fähigkeit ist danach ein eigenständig bereitstellbares Bauteil, das sich unabhängig austauschen und weiterentwickeln lässt. Eine feste Aufteilung in bestimmte Dienste und eine eigene Datenhaltung je Dienst schreibt die Allianz nicht vor. Das sind Texte der Anbieterseite, keine Norm (beide Seiten abgerufen am 13. Oktober 2026).
Ist nur die Oberfläche abgetrennt und der Rest bleibt ein System, sprechen Sie von Headless. Diese Entscheidung behandelt Headless Commerce: Wann sich die Trennung lohnt.
Die Bausteine und ihre Schnittstellen
Die Übersicht ordnet jedem Baustein die Aufgabe, den Weg zum Nachbarn und die Frage zu, die ins Angebot gehört. Die Einteilung ist unsere Arbeitsgliederung; welche Dienste ein Angebot tatsächlich trennt, steht in dessen Architekturbeschreibung.
| Baustein | Aufgabe | Schnittstelle zum Nachbarn | Im Angebot klären |
|---|---|---|---|
| Storefront (Frontend) | Liefert die Seiten an den Browser aus und zeigt Warenkorb und Kasse | HTTPS-Aufrufe an das Gateway; Vorlagen, Preise und Bestände kommen je Aufruf von dort | Wer betreibt die Vorlage, und wie viele Änderungen sind ohne Projekt möglich? |
| Gateway (API-Schicht) | Bündelt die Aufrufe, beendet die verschlüsselte Verbindung, setzt Zeitlimits | HTTPS von der Storefront hinein, HTTP zu den Diensten hinaus, Wege je Route | Welche Zeitlimits und Ratenbegrenzungen sind eingestellt, wer ändert sie? |
| Katalog und Produktdaten | Führt Produkte, Varianten, Preise, Texte und Bilder | Abruf über API, Massenänderung als Datei oder Ereignis | Welches System führt Preis und Bestand als Quelle, mit welcher Verzögerung? |
| Suche und Index | Findet Produkte, Filter und Sortierung | Der Index wird aus dem Katalog aufgebaut, Abfragen laufen über eine eigene API | Wie lange dauert ein vollständiger Neuaufbau des Index, wie alt darf er sein? |
| Warenkorb und Kasse | Hält den Warenkorb und löst die Bestellung aus | Aufrufe an Katalog, Suche, Zahlung und Bestelldienst; Sitzung per Cookie | Wo liegt der Warenkorb, und was passiert mit ihm, wenn ein Dienst nicht antwortet? |
| Zahlung | Nimmt die Zahlung an, prüft auf Betrug, meldet das Ergebnis zurück | Weiterleitung auf eine fremde Seite oder eingebettete Seite, Rückmeldung per HTTP-Aufruf (Webhook) | Wer betreibt die Zahlungsseite, und wie ist die Rückmeldung gegen fremde Aufrufe abgesichert? |
| Bestelldienst | Legt die Bestellung dauerhaft an und führt ihren Status | Aufruf aus der Kasse, Ereignisse an Warenwirtschaft, Versand und Nachrichtenversand | Erkennt der Dienst denselben Aufruf mit derselben Kennung als eine Bestellung? |
| Warenwirtschaft (ERP) | Führt Bestand, Rechnung, Versand und Buchhaltung | Datei- oder API-Abgleich in festen Abständen oder Ereignisse | Wer führt den Bestand, und was gilt für Bestellungen während der Abgleich nicht läuft? |
| Versand und Nachrichten | Erstellt Labels, meldet Sendestatus, verschickt Bestätigungen | API zum Versanddienst, Ereignisse zurück, E-Mails über einen Versanddienst | Wer verschickt Bestätigungen, wenn der Hauptweg zum Versanddienst fehlschlägt? |
| Protokollierung und Monitoring | Zeigt Aufrufe, Antwortzeiten und Fehler über alle Bausteine | Kennungen und Protokolle aus jedem Dienst, teils exportiert | Kann ich einen Vorgang über mehrere Dienste verfolgen, und wo liegen die Protokolle? |
Der BSI-Baustein APP.3.1 sieht als Standard-Anforderung vor, dass der Zugriff auf Hintergrundsysteme ausschließlich über definierte Schnittstellen und von definierten Systemen aus möglich sein soll und dass Datenverkehr über Netz- und Standortgrenzen hinweg authentisiert und verschlüsselt wird (IT-Grundschutz-Kompendium, Anforderung APP.3.1.A11, Edition 2023). Derselbe Baustein erwartet, dass der IT-Betrieb für die Auslieferung HTTP-Kopfzeilen wie Content-Security-Policy und Strict-Transport-Security setzt (Anforderung APP.3.1.A21); welcher Server oder Proxy das in Ihrem Aufbau tut, ist eine Architekturentscheidung. Das Kompendium ist ein Standard des BSI und kein Gesetz; verpflichtend wird es, wenn Recht oder Vertrag darauf verweisen.
Bei der Zahlung entscheidet der Aufbau über den Weg: Verlässt die Kundschaft den Shop per Weiterleitung auf eine fremde Seite, gehören Statuscodes und Rücksprungadresse zur Schnittstelle (RFC 9110, Abschnitt 15.4). Wer Zahlungswege vergleicht, findet die Kriterien im Artikel Zahlungsdienstleister für den Onlineshop wählen.
Was ein Ausfall je Baustein bedeutet
Die Tabelle ordnet jedem Baustein zu, was die Kundschaft merkt, was weiterläuft und welche erste Maßnahme den Schaden begrenzt. Sie ist eine Prüfliste für Ihr Projekt und keine Zusage über Anbieter.
| Baustein | Ausfall wirkt so | Was weiterläuft | Erste Maßnahme |
|---|---|---|---|
| Storefront | Keine Seite erreichbar, keine Bestellung möglich; die Dienste dahinter arbeiten weiter | Betrieb, Buchhaltung und Bestandsführung im Hintergrund | Zwischengespeicherte Seiten oder eine statische Auslieferung als Rückfall bereithalten |
| Gateway | Alle Wege hinter dem Gateway sind gesperrt, Seite und Kasse fallen gemeinsam aus | Kein Dienst ist über den normalen Weg erreichbar | Ersatzweg und Statusseite vorbereiten, Zeitlimits vorab prüfen |
| Katalog und Produktdaten | Produktseiten bleiben leer oder antworten mit Fehler, neue Preise erreichen die Kundschaft nicht | Warenkorb und Kundenkonto können weiterlaufen | Zuletzt bekannte Produktdaten zwischengespeichert ausliefern und Alter anzeigen |
| Suche und Index | Suche und Filter liefern keine Treffer; Kategorien bleiben nutzbar | Navigation über Kategorien, Produktseiten und Warenkorb | Suche ausblenden und auf Kategorien verweisen, Index neu aufbauen |
| Warenkorb und Kasse | Warenkorb geht verloren, Kauf bricht ab | Katalog und Suche bleiben lesbar | Warenkorb serverseitig halten, Weg zum erneuten Kauf anbieten |
| Zahlung | Bestellungen bleiben unbezahlt, Kasse bricht nach der Auswahl ab | Kauf auf Rechnung oder Vorkasse, wenn Sie ihn anbieten | Vorgänge beim Zahlungsdienst abgleichen und offene Zahlungen nachfassen |
| Bestelldienst | Zahlung ohne sichtbare Bestellung; Versand und Auswertung haben keine Grundlage | Der Vorgang bleibt beim Zahlungsdienst verbucht | Warteschlange zwischen Zahlung und Buchung, Abgleichliste gegen den Zahlungsdienst |
| Warenwirtschaft | Kein Bestand, keine Rechnung, kein Versandauftrag; Bestellungen sammeln sich | Der Shop nimmt Bestellungen weiter an, sofern die Bestandsführung im Shop mitläuft | Bestand im Shop reservieren, Buchungen nach dem Ausfall nachtragen |
| Versand und Nachrichten | Keine Labels, keine Sendungsverfolgung, keine Bestätigung; Rückfragen beim Kundendienst | Bestellung und Zahlung sind vorhanden | Labels beim Versanddienst nachziehen, Statusmeldungen nachsenden |
| Protokollierung und Monitoring | Der Ausfall wird von der Kundschaft gemeldet statt von Ihrem System | Der Betrieb läuft weiter, die Ursache bleibt zunächst unklar | Prüfung von außen einrichten: feste Abstände auf Startseite und Testbestellung |
Für die Bestellabwicklung ist der Bestelldienst der kritische Baustein: Fällt er aus, während die Zahlung durchläuft, entsteht eine Zahlung ohne sichtbaren Auftrag. Prüfen Sie deshalb, ob zwischen Zahlung und Buchung eine Warteschlange liegt und mit welcher Liste sich Buchungen des Zahlungsdienstes gegen Bestellungen abgleichen lassen.
Ein Rechenbeispiel: sechs Stationen bis zur Bestellung
Die folgende Beispielrechnung nutzt erfundene Werte. Der Weg von der Produktseite bis zur Bestellung führt über sechs Stationen und fünf Aufrufe: Storefront, Gateway, Katalog, Warenkorb, Zahlung und Bestelldienst.
| Aufruf | Beispielwert | Beispielwert im Fehlerfall |
|---|---|---|
| Storefront zu Gateway | 40 Millisekunden | 2.000 Millisekunden (Zeitlimit erreicht) |
| Gateway zu Katalog | 80 Millisekunden | 2.000 Millisekunden |
| Gateway zu Warenkorb | 30 Millisekunden | 2.000 Millisekunden |
| Warenkorb zu Zahlung | 400 Millisekunden | 2.000 Millisekunden |
| Kasse zu Bestelldienst | 50 Millisekunden | 2.000 Millisekunden |
| Summe | 600 Millisekunden | bis zu 10.000 Millisekunden |
Rechnung: Die fünf Aufrufe brauchen im Normalfall 40 + 80 + 30 + 400 + 50 = 600 Millisekunden. Mit einem Zeitlimit von zwei Sekunden je Aufruf wartet die Kundschaft im Fehlerfall bis zu 10 Sekunden (5 × 2.000 Millisekunden). Diese Zeit ist die Obergrenze der Kette, nicht die Antwortzeit des langsamsten Dienstes.
Dieselbe Kette wirkt auf die Verfügbarkeit, wenn eine Bestellung alle sechs Stationen braucht. Diese Beispielrechnung ist unser eigenes Modell und keine Messung; sie setzt voraus, dass jede Station zu 99,9 Prozent verfügbar ist, dass die Stationen unabhängig voneinander verfügbar sind und dass eine Bestellung nur zustande kommt, wenn alle sechs Stationen zugleich arbeiten. Sechs Stationen mit je 99,9 Prozent ergeben dann rechnerisch 0,999 hoch 6 = 0,9940, also rund 99,4 Prozent Verfügbarkeit; als Anteil eines Tages von 86.400 Sekunden sind das rund 518 Sekunden oder 8,6 Minuten. Fällt eine Station auf 99,0 Prozent, sinkt die Kette auf 0,999 hoch 5 × 0,99 = 0,9851, also rund 98,5 Prozent oder 21,5 Minuten je Tag. Die Prozentwerte gelten nur unter diesen Annahmen; die Tagesminuten sind die Umrechnung dieses Anteils und keine gemessene Ausfallzeit. Zusagen zur Verfügbarkeit stehen im Angebot, nicht in dieser Rechnung.
Typische Fehler
- Gemeinsame Datenbank statt Schnittstelle. Zwei Bausteine schreiben in dieselben Tabellen oder lesen sie direkt. Folge: Eine Änderung im einen Dienst bricht den anderen; sichtbar wird das an Fehlern in der Kasse nach einem Update, das nur ein System betraf. Dass jeder Dienst über eine eigene Schnittstelle geht, ist eine Architekturentscheidung: Der BSI-Baustein APP.3.1 verlangt Zugriff auf Hintergrundsysteme ausschließlich über definierte Schnittstellen (Anforderung APP.3.1.A11), verbietet eine gemeinsame Datenbank aber nicht.
- Wiederholung ohne Kennung. Ein Aufruf läuft in ein Zeitlimit und wird erneut gesendet, ohne dass der Empfänger ihn erkennt. Folge: eine zweite Bestellung oder eine doppelte Reservierung. Nach RFC 9110, Abschnitt 9.2.2, sind PUT, DELETE und die lesenden Methoden idempotent; POST zählt nicht dazu, und ein Client soll ihn ohne weitere Vorkehrung nicht automatisch wiederholen. Solange der Dienst keine eigene Kennung auswertet, kann ein wiederholter Aufruf dieselbe Wirkung mehrfach auslösen; eine Kennung ist eine mögliche Umsetzung.
- Kein Zeitlimit und keine Pause zwischen Wiederholungen. Ein langsamer Dienst bindet alle Verbindungen, der Ausfall breitet sich aus. Folge: Der Gateway antwortet mit 504 Gateway Timeout, wenn ein aufgerufener Dienst nicht rechtzeitig antwortet (RFC 9110, Abschnitt 15.6.5); ein überlasteter Dienst kann mit 503 und dem Feld Retry-After antworten (Abschnitte 15.6.4 und 10.2.3).
- Zwischenspeicher ohne Verfallsregel. Preise, Bestände oder Warenkörbe liegen länger im Zwischenspeicher als gedacht. Folge: Die Kundschaft sieht einen alten Preis, der im Checkout nicht mehr gilt; eine Antwort gilt als veraltet, wenn ihre Frischezeit abgelaufen ist (RFC 9111, Abschnitt 4.2).
- Keine gemeinsame Kennung über die Dienste. Jeder Anbieter protokolliert für sich. Folge: Bei einer Fehlermeldung endet die Spur am Rand des ersten Dienstes. Der W3C-Standard Trace Context beschreibt dafür die Kopfzeilen traceparent und tracestate (Recommendation vom 23. November 2021), mit denen eine Kennung von Dienst zu Dienst weitergereicht wird.
- Keine Regel für Versionssprünge. Ein Baustein ändert Felder, die Nachbarn weiterhin lesen. Folge: Der Fehler tritt erst nach der Aktualisierung auf. Semantic Versioning 2.0.0 sieht für unvereinbare Änderungen an einer Schnittstelle eine neue Hauptversionsnummer vor; verpflichtend wird das nur, wenn ein Vertrag es verlangt.
So gehen Sie vor
- Zeichnen Sie jeden Vorgang als Kette, nicht nur den Kauf: Bestellung, Retoure, Preisänderung, Bestandsänderung und Kundenkonto. Notieren Sie je Kante Protokoll, Richtung und Datenart.
- Klären Sie je Schnittstelle, wer die Daten führt, wie oft abgeglichen wird, welches Zeitlimit gilt, ob Wiederholungen möglich sind und wer außerhalb der Geschäftszeiten erreichbar ist. Der BSI-Baustein OPS.2.2 verlangt dafür eine Service-Definition sowie dokumentierte Schnittstellen und Verantwortlichkeiten (Anforderungen A3 und A4, Edition 2023).
- Füllen Sie die Ausfalltabelle für Ihre Ketten aus und legen Sie je Zeile fest, welchen Rückfall Sie akzeptieren: Zwischenspeicher, Warteschlange oder Handarbeit. Der Baustein OPS.2.2 verlangt außerdem eine Regelung für die Beendigung des Verhältnisses (A14) und nennt Portabilitätstests bei erhöhtem Schutzbedarf (A15).
- Lassen Sie sich Belege zeigen statt Zusagen: eine Schnittstellenbeschreibung im Format OpenAPI (Fassung 3.2.1 vom 10. September 2026), eine Testumgebung mit Ihren Daten, einen Fehlerkatalog und einen Datenexport im dokumentierten Format. Eine Prüfliste liefert Schnittstellen eines Shopsystems prüfen.
- Regeln Sie vertraglich, wer welche Schnittstelle betreibt, welche Antwortzeit zugesagt ist, wie der Ausstieg abläuft und wie ein Wiederherstellungstest nachgewiesen wird. Der Baustein CON.3 fordert als Basis-Anforderung, dass Datensicherungen regelmäßig getestet werden, vor allem das Zurückspielen in angemessener Zeit (Anforderung CON.3.A15). Halten Sie die Liste danach aktuell: Jeder neue Baustein und jede neue Version ändert die Ketten.