Neuer Checkout im E-Commerce

Buy ist ein Self-Contained System. Es hält Produkt-, Preis-, Verfügbarkeits- und Kundendaten als eigene Repliken vor, die über Kafka aus den anderen Vertikalen einlaufen. Der Warenkorb bleibt damit arbeitsfähig, wenn ein Nachbarsystem gerade nicht antwortet. Schnell ist er auch, weil er für eine Preisauskunft keinen fremden Service aufrufen muss.

Preise und Verfügbarkeiten können sich ändern, während ein Warenkorb offen liegt. Er aktualisiert sich deshalb über Server-Sent Events und wartet nicht auf den nächsten Klick.

Welche Filiale, welches Lager oder welcher Marktplatzpartner eine Bestellung am Ende ausliefert, entscheidet nachgelagert das Order-Management-System. Der Warenkorb trifft diese Entscheidung nicht, er muss sie aber möglich machen: Was er zusagt, muss verfügbar sein.

Das ist schwieriger, als es klingt. Bestände in Zentrallager, einzelnen Filialen und bei Marktplatzpartnern ändern sich unabhängig voneinander, und ein Verkauf im Shop verändert sie ebenfalls. Weichen Bestandslage und laufende Verkäufe auseinander, fällt der Fehler im Checkout nicht auf. Er zeigt sich Tage später als Storno beim Kunden. Dafür haben wir im selben Projekt ein eigenes Bestandssystem gebaut → Zum Showcase Bestandssystem

Zahlungen laufen über Adyen. Zum Go-Live waren sie bewusst auf PayPal und Klarna mit Rechnungskauf und Ratenzahlung reduziert. Von Beginn an dabei sind außerdem zwei Bezahlwege, die den Kaufabschluss fachlich deutlich anspruchsvoller machen als eine reine Kartenzahlung: Geschenkkarten über epay und Club-Punkte über Convercus.

Beide decken eine Bestellung in der Regel nur teilweise. Ein Kaufabschluss ist damit selten eine einzelne Zahlung, meist ist er eine Kombination aus mehreren. Diese Kombination muss vollständig aufgehen, auch wenn ein Teil davon fehlschlägt. Und sie muss sich rückabwickeln lassen, ohne dass ein Guthaben verschwindet. An diesen Fällen entscheidet sich, ob ein Checkout im Betrieb ruhig bleibt.

Ein Fehler im Katalog kostet einen Klick, ein Fehler im Kaufabschluss kostet die Bestellung. Entsprechend sieht die Absicherung aus. Zu den klassischen Unit- und Integrationstests kommen Property-Based Tests mit jqwik. Sie gehen über einzelne Beispiele hinaus und prüfen Eigenschaften, die für alle Eingaben gelten müssen: Preissummen, Rabattverrechnung, Zustandsübergänge im Warenkorb. Die Integrationstests laufen gegen eine echte PostgreSQL-Instanz und nicht gegen eine Attrappe. In die Deployment-Pipeline sind außerdem Akzeptanztests gegen die Staging-Umgebung eingebaut, die vor jedem Produktions-Release laufen.

Neue Funktionen gehen über Feature Flags in Betrieb und hängen damit nicht an Release-Terminen. Der Produktionsdeploy bleibt bewusst ein manueller Schritt.

Zwölf Monate für eine neue Commerce-Plattform funktionieren nur mit einer unbequemen Konsequenz: Vieles, was im E-Commerce als Standard gilt, war zum Start nicht dabei. Es gab keine Mengenänderung im Warenkorb, keine durchgestrichenen Preise oder Rabatte im Checkout, kein Click & Collect und nur zwei Zahlarten. Der Maßstab war die Frage, ob Kundinnen und Kunden einen Kauf abschließen können. Vollständigkeit war es nicht.

Aufschlussreich ist auch, was geblieben ist. Geschenkkarten und Club-Punkte waren vom ersten Tag an dabei, obwohl sie technisch aufwendiger sind als eine Mengenänderung im Warenkorb. Priorisiert wurde danach, was für INTERSPORT Kund:innen zwingend zum Kaufabschluss dazugehört. Der Implementierungsaufwand gab dabei nicht den Ausschlag.

Das erklärte Ziel des Programms war, externe Abhängigkeit zu beenden. Wir waren in genau diesem Vorhaben der externe Partner und hatten den Auftrag, uns überflüssig zu machen.

Deshalb lief beides parallel. Während unser vierköpfiges Team die Vertikale Buy gebaut hat, stellte INTERSPORT drei eigene Entwickler:innen ein. Wir haben sie vom ersten Tag an ins Team geholt, als Mitautor:innen des Systems, das sie übernehmen sollten. Zuschauer:innen einer Übergabe am Ende sollten sie nie sein. Pairing, gemeinsame Reviews und geteilte Verantwortung für Betrieb und Releases waren der Normalfall.

Das kostet in den ersten Wochen Tempo, denn ein eingespieltes Dienstleisterteam liefert schneller, wenn es unter sich bleibt. Dafür kennt das Team die Entscheidungen hinter dem Code, weil es dabei war, als sie getroffen wurden.

Ein Go-Live ist der denkbar schlechteste Zeitpunkt, um ein System aus der Hand zu geben. Unser Auftrag endete deshalb nicht im Januar 2025. Wir sind noch neun Monate geblieben, allerdings mit zwei Entwicklern statt vier.

Diese Halbierung war unser Übergabemechanismus. Was das interne Team übernehmen konnte, hat es übernommen. Was noch nicht saß, haben wir gemeinsam gemacht und dem Team nicht abgenommen. In dieser Zeit sind wir vom Team, das baut, zum Team geworden, das gefragt wird. Am Ende wurden wir nicht mehr gefragt. Parallel dazu haben die beiden verbliebenen Entwickler das Bestandssystem weiter ausgebaut → Zum Showcase Bestandssystem

Ein Team kann nur übernehmen, was es lesen, verstehen und gefahrlos ändern kann. Einiges war deshalb von Anfang an nicht verhandelbar. Die Ports-and-Adapters-Struktur hält die Fachlogik unabhängig von Datenbank, Kafka und HTTP. Die Testsuite sichert eine Änderung auch dann ab, wenn die Person, die den Code geschrieben hat, nicht mehr im Raum ist. Dokumentation und API-Spezifikation liegen im Repository und nicht im Confluence, Backstage dient als Einstieg. Automatisierte Dependency-Updates sorgen dafür, dass das System nicht in dem Moment veraltet, in dem wir gehen.

Die neue Plattform ist das Ergebnis mehrerer Teams und Partner, die Zahlen gelten über alle fünf Vertikalen hinweg. INTERSPORT berichtet für die Zeit nach dem Go-Live von einem Wachstum des Gross Order Value von 18,13 Prozent im Jahresvergleich und 15,98 Prozent über Plan. Hinzu kommen deutlich verbesserte Kundenbewertungen auf Trustpilot und Idealo sowie 41 Prozent geringere externe Kundenservicekosten.