Das Ende des nächtlichen CSV-Exports
Überverkäufe in Kampagnen sind fast nie ein Lagerproblem. Es ist eine sechzehn Stunden alte Bestandsdatei — und ihr Ersatz ist eine Frage der Idempotenz.
Fragen Sie einen Händler, warum er am Black Friday überverkauft hat, und Sie hören etwas über das Lager. Schauen Sie in die Schnittstelle, und Sie finden meist eine CSV-Datei, die um 02:00 Uhr das ERP verlässt und um 02:40 Uhr im Shop landet — und den Bestand vom Vorabend beschreibt.
Den grössten Teil des Jahres ist dieser Verzug unsichtbar. Während einer Kampagne kann eine Stunde Traffic eine Grössenstaffel leerräumen, und jede Bestellung danach ist eine Erstattung, ein Servicekontakt und eine Kundin, die nicht wiederkommt.
Die Datei durch einen Ereignisstrom zu ersetzen, ist der einfache Teil. Der schwierige: Der Shop erhält nun Tausende kleiner Aktualisierungen statt einer grossen, und jede davon kann doppelt, in falscher Reihenfolge oder gar nicht ankommen.
Die Regeln zählen also mehr als der Transportweg. Jede Nachricht trägt eine Version und einen Idempotenzschlüssel. Dieselbe Nachricht zweimal anzuwenden, bewirkt nichts. Eine ältere Nachricht nach einer neueren wird verworfen statt geschrieben. Eine fehlgeschlagene Nachricht geht in eine Dead-Letter-Queue, die ein Mensch prüfen kann — nicht in ein Protokoll, das niemand liest.
Wir behalten die nächtliche Datei ausserdem eine Weile, aber als Abgleichlauf statt als führende Quelle. Widersprechen sich Strom und Datei um 03:00 Uhr, bekommt jemand eine Warnung mit den konkreten Artikelnummern. Diese Parallelphase ist es, die den Umstieg langweilig macht.
Bei einem Händler mit vierzig Märkten ging die Bestandsgenauigkeit damit von „meistens in Ordnung“ zu einer messbaren Zahl, und Überverkäufe in Kampagnen fielen praktisch auf null. Am Shop selbst hat sich nichts geändert.