Checkout

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 ist damit auch dann arbeitsfähig, wenn ein Nachbarsystem gerade nicht antwortet - und er ist schnell, weil er für jede Preisauskunft keinen fremden Service aufrufen muss.

Weil sich Preise und Verfügbarkeiten ändern können, während ein Warenkorb offen liegt, aktualisiert sich dieser über Server-Sent Events, statt auf den nächsten Klick zu warten.

Welche Filiale, welches Lager oder welcher Marktplatzpartner eine Bestellung am Ende ausliefert, entscheidet nachgelagert das Order-Management-System. Der Warenkorb muss diese Entscheidung nicht treffen - aber er muss dafür sorgen, dass sie überhaupt möglich ist. Was er zusagt, muss verfügbar sein.

Das klingt trivial und ist es nicht: Bestände über Zentrallager, einzelne Filialen und Marktplatzpartner ändern sich unabhängig voneinander, und ein Verkauf im Shop verändert sie ebenfalls. Weichen Bestandslage und laufende Verkäufe auseinander, kommt der Fehler nicht im Checkout heraus, sondern Tage später als Storno beim Kunden. Genau dafür haben wir im selben Projekt ein eigenes Bestandssystem gebaut → Zum Showcase Bestandssystem

Zahlungen laufen über Adyen - zum Go-Live bewusst reduziert auf PayPal und Klarna mit Rechnungskauf und Ratenzahlung. Dazu kommen von Beginn an 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 Zahlung, sondern eine Kombination aus mehreren - die vollständig aufgehen muss, auch wenn ein Teil davon fehlschlägt, und die sich rückabwickeln lassen muss, ohne dass ein Guthaben verschwindet. Genau diese Fälle entscheiden darüber, 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: Neben klassischen Unit- und Integrationstests prüfen Property-Based Tests mit jqwik nicht einzelne Beispiele, sondern Eigenschaften, die für alle Eingaben gelten müssen - Preissummen, Rabattverrechnung, Zustandsübergänge im Warenkorb. Integrationstests laufen gegen eine echte PostgreSQL-Instanz statt gegen eine Attrappe. Und in die Deployment-Pipeline sind Akzeptanztests gegen die Staging-Umgebung eingebaut, die vor jedem Produktions-Release laufen.

Neue Funktionen gehen über Feature Flags in Betrieb, nicht über Release-Termine. 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. Keine Mengenänderung im Warenkorb, keine durchgestrichenen Preise oder Rabatte im Checkout, kein Click & Collect, nur zwei Zahlarten. Der Maßstab war nicht Vollständigkeit, sondern die Frage, ob Kundinnen und Kunden einen Kauf abschließen können.

Was blieb, ist genauso aufschlussreich wie das, was fiel: Geschenkkarten und Club-Punkte waren vom ersten Tag an dabei - obwohl sie technisch aufwendiger sind als eine Mengenänderung im Warenkorb. Priorisiert wurde nicht nach Implementierungsaufwand, sondern danach, was für INTERSPORT Kund:innen zwingend zum Kaufabschluss dazugehört.

Das erklärte Ziel des Programms war, externe Abhängigkeit zu beenden. Wir waren der externe Partner in genau diesem Vorhaben - mit dem 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, die wir vom ersten Tag an ins Team geholt haben. Nicht als Zuschauer:innen einer Übergabe am Ende, sondern als Mitautor:innen des Systems, das sie übernehmen sollten. Pairing, gemeinsame Reviews und geteilte Verantwortung für Betrieb und Releases waren der Normalfall, nicht die Ausnahme.

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

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

Diese Halbierung war der eigentliche Übergabemechanismus. Was das interne Team übernehmen konnte, hat es übernommen; was noch nicht saß, wurde gemeinsam gemacht, nicht für das Team erledigt. Wir sind in dieser Zeit vom Team, das baut, zum Team geworden, das gefragt wird - und am Ende nicht mehr gefragt wurde. 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. Deshalb war einiges von Anfang an nicht verhandelbar: Eine Ports-and-Adapters-Struktur, in der die Fachlogik unabhängig von Datenbank, Kafka und HTTP steht. Eine Testsuite, die eine Änderung auch dann absichert, wenn die Person, die den Code geschrieben hat, nicht mehr im Raum ist. Dokumentation und API-Spezifikation im Repository statt im Confluence, mit Backstage als Einstieg. Automatisierte Dependency-Updates, damit das System nicht in dem Moment veraltet, in dem wir gehen.

Die neue Plattform ist das Ergebnis mehrerer Teams und Partner. Über alle fünf Vertikalen hinweg berichtet INTERSPORT 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, von deutlich verbesserten Kundenbewertungen auf Trustpilot und Idealo sowie von 41 Prozent geringeren externen Kundenservicekosten.