Neues Bestandssystem im E-Commerce

Das System führt den Bestand aus zwei Quellen zusammen. Die Händler und die Zentrallager melden ihre Bestände an die Zentrale, und zwar mehrmals untertägig und nicht nur einmal über Nacht. Außerdem ist das System an das Order-Management-System angebunden. Darüber kennt es die unfakturierten Aufträge und jeden weiteren Schritt im Prozess: Versand, Händlerstorno und alles, was einen Bestand sonst noch bewegt. Diese Ereignisse laufen per Push ein, nicht per Abfrage.

Erst beides zusammen ergibt eine belastbare Aussage. Der gemeldete Bestand ist schon veraltet, sobald er ankommt. Ihn korrigieren die Verkäufe, die seitdem passiert sind. Diese Verrechnung war im Altsystem nicht möglich.

Die abhängigen Systeme fragen nicht bei jedem Klick nach. Sie halten den für sie relevanten Ausschnitt als eigene Replik vor, und Kafka hält diese Replik laufend aktuell. Der Warenkorb der Vertikale Buy ist der prominenteste dieser Verbraucher → Zum Showcase Checkout

Der übliche Weg, Überverkäufe zu verhindern, ist eine Reservierung: Die Ware wird beim Betreten des Checkouts für einige Minuten gesperrt. Wir haben bewusst darauf verzichtet.

Eine Reservierung ist im Kern ein Umgang mit Unsicherheit. Man sperrt Ware, weil man nicht genau weiß, wie viel davon noch da ist. Wer den Bestand zeitnah kennt, braucht diese Absicherung nicht. Sie hat außerdem ihren Preis, denn jede Sperre blockiert Ware, die jemand anders in derselben Minute gekauft hätte. Bei Filialware im Einzelstück ist das der Normalfall. Wir haben deshalb die Genauigkeit verbessert und sperren keine Ware weg. Wer zuerst kauft, bekommt sie.

Der Auftrag lautete, die Fachlichkeit des Altsystems neu zu schneiden. Eine Modernisierung war nicht gefragt. Aus dem Monolithen wurde eine ereignisgetriebene Architektur mit Apache Kafka auf AWS MSK als Rückgrat. Einzelne Services reagieren jetzt auf Bestands- und Auftragsereignisse. Die nächtliche Verarbeitung, die den ganzen Datenbestand durchging, gibt es nicht mehr.

Der Zuschnitt folgt der Aufgabe und keinem Architekturideal. Die meisten Services sind AWS Lambdas, die von MSK-Ereignissen ausgelöst werden. Manche Quellen melden nicht selbst und müssen abgefragt werden. Dafür laufen Kotlin-Services auf ECS. Polling braucht einen Prozess, der wartet, und dafür ist eine Funktion das falsche Werkzeug.

Der alte Shop setzte auf dem alten Bestandssystem auf. Beide hingen damit voneinander ab und ließen sich nicht nacheinander ersetzen. Wir haben deshalb zuerst den neuen Datenstand im Parallelbetrieb aufgebaut und mit dem alten abgeglichen. Dann haben wir beide Altsysteme zum selben Zeitpunkt durch ihre Nachfolger abgelöst.

Ein Bestandssystem lässt sich vor dem Start nicht fertig bauen. Erst der Betrieb zeigt, wie sich Bestände tatsächlich bewegen: welche Quellen ungenau melden, wo der Takt nicht reicht, an welcher Stelle ein Prozessschritt zu spät ankommt. Wir sind deshalb nach dem Go-Live noch neun Monate geblieben, mit zwei Entwicklern statt vier.

Zuerst haben wir die Stornoquote überhaupt sichtbar gemacht. Vorher hatte sie niemand täglich als Zahl vor Augen, sie war ein Nebenprodukt vieler Einzelfälle. Erst als sie messbar war, ließ sie sich systematisch senken: von über fünf Prozent auf unter 1,25 Prozent.

Das erklärte Ziel des Programms war, die Abhängigkeit von externen Dienstleistern zu beenden. Wir haben deshalb parallel zum Bau das interne Team aufgebaut, das die Vertikale heute verantwortet. Die drei neuen Entwickler:innen waren vom ersten Tag an im Team und kamen nicht erst zu einer Übergabe am Ende dazu. Nach dem Go-Live haben wir von vier auf zwei Entwickler verkleinert. Das war kein Sparzwang, darüber lief die Übergabe. Einer der beiden hat in dieser Phase die Product-Owner-Aufgaben für das Bestandssystem übernommen, bis die Fachlichkeit intern verankert war. Wie das funktioniert hat, steht ausführlich im Checkout-Showcase → Zum Showcase Checkout