Bestandssystem

Der Bestand ergibt sich aus zwei Quellen, die das System zusammenführt. Zum einen melden die Händler und die Zentrallager ihre Bestände an die Zentrale - mehrmals untertägig, nicht einmal über Nacht. Zum anderen ist das System an das Order-Management-System angebunden und kennt darüber die unfakturierten Aufträge sowie 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 allein ist immer schon veraltet, sobald er ankommt - was ihn korrigiert, sind die Verkäufe, die seitdem passiert sind. Genau 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, die über Kafka laufend aktualisiert wird. Der Warenkorb der Vertikale Buy ist der prominenteste dieser Verbraucher → Zum Showcase Checkout

Der übliche Weg, Überverkäufe zu verhindern, ist eine Reservierung: 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 und zahlt für sie einen Preis: Jede Sperre blockiert Ware, die jemand anders in derselben Minute gekauft hätte. Bei Filialware im Einzelstück ist das kein Randfall, sondern der Normalfall. Wir haben deshalb die Genauigkeit verbessert, statt Ware wegzusperren. Wer zuerst kauft, bekommt sie.

Der Auftrag war nicht, das Altsystem zu modernisieren, sondern seine Fachlichkeit neu zu schneiden. Aus dem Monolithen wurde eine ereignisgetriebene Architektur mit Apache Kafka auf AWS MSK als Rückgrat: Einzelne Services, die auf Bestands- und Auftragsereignisse reagieren, statt einer nächtlichen Verarbeitung, die den ganzen Datenbestand durchgeht.

Der Zuschnitt folgt dabei der Aufgabe, nicht einem Architekturideal. Die meisten Services sind AWS Lambdas, die von MSK-Ereignissen ausgelöst werden. Wo Quellen abgefragt statt gemeldet werden, laufen stattdessen 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 - und dann beide Altsysteme zum selben Zeitpunkt durch ihre Nachfolger abgelöst.

Ein Bestandssystem lässt sich vor dem Start nicht fertig bauen. Erst der echte 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.

Der erste Schritt war, die Stornoquote überhaupt sichtbar zu machen. Sie war vorher keine Zahl, die jemand täglich vor Augen hatte, sondern 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 nicht nur gebaut, sondern parallel das interne Team aufgebaut, das die Vertikale heute verantwortet - drei neue Entwickler:innen, vom ersten Tag an im Team statt in einer Übergabe am Ende. Die Verkleinerung von vier auf zwei Entwickler nach dem Go-Live war dabei kein Sparzwang, sondern der Übergabemechanismus selbst. 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