Das verlorene Update: wenn zwei Automatisierungen denselben Datensatz überschreiben
Zwei Workflows ändern im selben Moment denselben Kontakt, jeder schreibt den ganzen Datensatz zurück, und eine Änderung verschwindet spurlos. Warum das passiert und wie wir verhindern, dass Automatisierungen sich gegenseitig die Arbeit löschen.
Eine Anreicherung verschwand spurlos, weil zwei Workflows im selben Moment denselben Kontakt anfassten
Ein Kunde hatte zwei Automatisierungen auf demselben CRM-Kontakt laufen. Die erste holte sich bei einem Datendienst die Firmengröße und schrieb sie ins Kontaktprofil. Die zweite setzte die Lebenszyklus-Phase hoch, sobald jemand ein Formular ausfüllte. Beide harmlos, beide seit Monaten im Einsatz.
An einem Vormittag füllte ein bestehender Lead ein Formular aus, und im selben Moment lief die nächtlich angestoßene Anreicherung nach. Beide Workflows griffen sich denselben Kontakt, im Abstand von vielleicht zwei Sekunden. Die Anreicherung las den Datensatz, ergänzte die Firmengröße und schrieb den ganzen Kontakt zurück. Eine Sekunde später schrieb auch die Formular-Automatisierung den ganzen Kontakt zurück, mit der neuen Lebenszyklus-Phase, aber mit der alten, leeren Firmengröße, weil sie den Datensatz vor der Anreicherung gelesen hatte. Die gerade ergänzte Firmengröße war weg. Kein Fehler, kein Hinweis, einfach überschrieben.
Das Problem heißt "Lost Update", und es ist alt
Was hier passiert, hat einen Namen, den Datenbankleute seit Jahrzehnten kennen: das verlorene Update. Drei Schritte, die fast jeder Workflow macht, ohne dass man darüber nachdenkt. Lesen, ändern, zurückschreiben. Solange nur ein Prozess das tut, ist alles gut. Sobald zwei Prozesse denselben Datensatz im selben Zeitfenster lesen, ändern und zurückschreiben, gewinnt der, der zuletzt schreibt. Und "gewinnt" heißt: Er überschreibt die Änderung des anderen mit einem Stand, der schon veraltet war, als er ihn gelesen hat.
Das ist kein exotischer Sonderfall. Es passiert immer dann, wenn zwei Auslöser zufällig nah beieinander liegen. Genau deshalb ist es so tückisch: In der Testphase tritt es nie auf, weil man Fälle einzeln durchspielt. Im Betrieb tritt es selten auf, aber regelmäßig, und jedes Mal verschwindet leise eine Information.
Warum No-Code es schlimmer macht
Schreibt man Software von Hand, kann man der Datenbank sagen: Ändere nur dieses eine Feld. Die meisten No-Code-Module können das nicht sauber. Sie holen den kompletten Datensatz, Sie mappen ein paar Felder, und das Modul schreibt den kompletten Datensatz zurück, inklusive aller Felder, die Sie gar nicht angefasst haben. Jeder Schreibvorgang ist damit ein Vollbild, das alles übermalt, was zwischenzeitlich jemand anderes geändert hat.
Dazu kommt, dass die einzelnen Workflows nichts voneinander wissen. Jeder fühlt sich an wie ein abgeschlossenes kleines Programm. Dass der CRM-Datensatz ein gemeinsamer Speicher ist, auf den mehrere gleichzeitig zugreifen, sieht man dem einzelnen Szenario nicht an. Man baut jeden Workflow so, als wäre er allein mit den Daten.
Woran Sie es überhaupt bemerken
Das Heimtückische ist, dass nichts auf einen Fehler hindeutet. Beide Workflows melden Erfolg, beide Läufe stehen grün im Protokoll. Auffällig wird es erst, wenn jemand bemerkt, dass ein Feld, das gestern noch gefüllt war, heute wieder leer ist. Wer dem nachgeht, findet im Verlauf des Datensatzes oft zwei Schreibvorgänge wenige Sekunden auseinander, und der zweite trägt den alten Wert. Genau dieses Muster, ein Feld, das sich scheinbar von selbst zurücksetzt, ist das verräterische Zeichen. Wenn ein Kollege sagt, ein Wert verschwinde immer mal wieder, lohnt sich der Blick darauf, welche Automatisierungen denselben Datensatz anfassen.
Vier Wege, das zu verhindern
Schreiben Sie nur das Feld, das Sie geändert haben. Wenn die API einen partiellen Schreibvorgang erlaubt, also nur die Firmengröße statt des ganzen Kontakts, kollidieren zwei Workflows, die unterschiedliche Felder anfassen, gar nicht erst. Das löst den häufigsten Fall fast vollständig.
Geben Sie jedem Feld genau einen Besitzer. Wenn nur ein einziger Workflow je die Firmengröße schreibt und nur ein einziger die Lebenszyklus-Phase, kann keiner dem anderen ins Feld pfuschen. Klare Zuständigkeit auf Feldebene ist die einfachste organisatorische Antwort, und sie kostet nichts außer Disziplin.
Serialisieren Sie Schreibzugriffe auf denselben Datensatz. Statt dass mehrere Workflows direkt ins CRM schreiben, schicken alle ihre Änderungen durch eine Warteschlange, die sie nacheinander abarbeitet. Dann gibt es kein "im selben Moment" mehr.
Nutzen Sie eine Versionsprüfung, wenn die Gegenseite sie anbietet. Manche APIs merken sich, in welcher Version Sie den Datensatz gelesen haben, und lehnen Ihren Schreibvorgang ab, falls sich der Datensatz seitdem geändert hat. Sie bekommen dann einen Fehler statt einer stillen Überschreibung und können den Datensatz neu lesen und Ihre Änderung erneut anwenden.
Das ist nicht dasselbe wie Idempotenz
Die beiden Themen werden gern verwechselt. Idempotenz schützt davor, dass derselbe Auslöser zweimal verarbeitet wird, etwa wenn ein Webhook doppelt ankommt. Hier geht es um etwas anderes: zwei verschiedene Auslöser, die zufällig gleichzeitig denselben Datensatz anfassen. Eine idempotente Verarbeitung hilft gegen das verlorene Update nicht, weil beide Schreibvorgänge für sich genommen völlig korrekt sind. Sie stehen sich nur gegenseitig im Weg.
Das Muster dahinter
Auch das ist am Ende eine Frage der Grundannahme. Ein Workflow fühlt sich isoliert an, ist es aber nicht. Er teilt sich seine Datensätze mit jedem anderen Workflow, der auf dieselben Objekte zugreift, oft mit welchen, die ganz woanders gebaut wurden und von denen niemand mehr weiß. Wer eine neue Automatisierung baut, sollte deshalb nicht nur fragen, was sie tun soll, sondern auch, wer sonst noch an dieselben Felder schreibt. Die verschwundene Firmengröße fiel niemandem auf, weil nichts kaputtging. Es fehlte nur etwas, das vorher kurz da gewesen war.