Rollback ist eine Illusion: Was passiert, wenn Ihre Automatisierung mittendrin abbricht

Ein Kunde hatte 1.400 Euro bezahlt, aber es gab keine Bestellung

An einem Dienstagmorgen rief uns ein Onlinehändler an, ziemlich blass. Ein Kunde hatte bezahlt, die Kreditkarte war belastet, das Geld war eingegangen. Nur existierte die zugehörige Bestellung nirgends. Nicht im Warenwirtschaftssystem, nicht in der Versandsoftware, nicht im Kundenkonto. Jemand wartete auf Ware, die niemand je packen würde, weil kein System wusste, dass sie bestellt war.

Dahinter lag eine Automatisierung mit fünf Schritten: Karte belasten, Bestellung im ERP anlegen, Lagerbestand reduzieren, Versandlabel erzeugen, Bestätigung senden. Schritt eins lief sauber durch. Schritt zwei brach ab, weil das ERP für vierzig Sekunden nicht antwortete. Die Automatisierung stoppte mit einer Fehlermeldung, die an dem Morgen niemand las. Das Geld war gebucht, die Bestellung nie entstanden.

Die Frage des Händlers war die naheliegende: "Kann das Ding nicht einfach zurückrollen, wenn ein Schritt schiefgeht?" Die ehrliche Antwort war nein. Und warum das so ist, ist der eigentliche Grund für diesen Text. Denn dieses Missverständnis steckt in sehr vielen Automatisierungen, auch in solchen, die seit Monaten laufen und noch keinen Ärger gemacht haben. Bis sie es tun.

Warum "Rollback" das falsche Wort ist

Der Begriff Rollback kommt aus der Datenbankwelt. Dort gibt es Transaktionen: eine Klammer um mehrere Schreibvorgänge, die entweder komplett passieren oder gar nicht. Buchen Sie in einer Datenbank Geld von Konto A nach Konto B, und der zweite Teil scheitert, macht die Datenbank den ersten Teil rückgängig, als wäre nichts gewesen. Alles oder nichts. Das ist eine der besten Ideen der Informatik, und sie funktioniert, weil ein einziges System die volle Kontrolle über alle beteiligten Daten hat.

Eine No-Code-Automatisierung hat diese Kontrolle nicht. Jeder Schritt spricht mit einem anderen fremden System: der Zahlungsdienstleister, das ERP, das Lager, der Versanddienstleister, der Mailserver. Jedes dieser Systeme entscheidet für sich, und jedes committet sofort. In dem Moment, in dem die Kreditkarte belastet ist, ist sie belastet. Es gibt keine Klammer, die diese fünf Systeme umschließt. Es gibt keinen gemeinsamen Zurück-Knopf, weil es keine gemeinsame Instanz gibt, die ihn drücken könnte.

Genau hier bricht das mentale Modell der meisten Leute. Sie stellen sich die Automatisierung wie ein Programm vor, das notfalls sagt "war doch nichts". Tatsächlich ist sie eher eine Kette von Anrufen bei fünf verschiedenen Behörden. Legt die dritte Behörde auf, sind die ersten beiden Anrufe trotzdem passiert. Sie können nicht so tun, als hätten Sie nie angerufen.

Make, n8n, Zapier und die anderen tun nichts, um daran etwas zu ändern. Sie führen Schritte nacheinander aus. Bricht einer ab, bleiben die vorherigen so, wie sie sind. Das ist keine Schwäche eines bestimmten Werkzeugs, das ist die Natur des Problems. Wer auf die Suche nach der Plattform geht, die "richtiges Rollback" kann, sucht nach etwas, das es nicht geben kann, solange fremde Systeme im Spiel sind.

Was bei einem Teilfehler wirklich passiert

Wenn eine mehrstufige Automatisierung in der Mitte abbricht, entsteht kein Fehler im klassischen Sinn. Es entsteht ein Zustand, der halb passiert ist. Und halb passiert ist oft schlimmer als gar nicht passiert, weil niemand ihn sofort bemerkt.

Ein paar Beispiele aus der Praxis, alle echt, nur anonymisiert:

Ein Newsletter-Tool trug einen neuen Kontakt ein und sollte anschließend im CRM ein Feld setzen. Der erste Schritt lief, der zweite nicht. Ergebnis: eine Person bekam wochenlang Marketingmails, obwohl sie im CRM als "kein Kontakt erwünscht" geführt wurde. Das fiel erst auf, als sie sich beschwerte.

Eine Automatisierung legte in einem Projektmanagement-Tool eine Aufgabe an und sollte danach den zuständigen Mitarbeiter benachrichtigen. Die Aufgabe entstand, die Benachrichtigung nicht. Die Aufgabe lag drei Wochen unbearbeitet da, weil der Mitarbeiter schlicht nicht wusste, dass es sie gab.

Ein Buchhaltungs-Workflow verbuchte eine Zahlung und sollte danach die zugehörige Rechnung auf "bezahlt" setzen. Der erste Teil lief, der zweite scheiterte an einem Zeichenlimit. Die Mahnstufe lief weiter. Der Kunde bekam eine Zahlungserinnerung für eine Rechnung, die er längst beglichen hatte.

In allen drei Fällen gab es keinen roten Alarm. Die Systeme waren nicht kaputt. Sie waren nur uneins. Zwei Datenbestände, die eigentlich dasselbe erzählen sollten, erzählten Verschiedenes. Solche stillen Widersprüche sind die eigentliche Gefahr, nicht der laute Absturz. Ein Absturz zwingt jemanden zum Hinsehen. Ein halber Erfolg lächelt und schweigt.

Die drei ehrlichen Strategien

Wenn Rollback keine Option ist, was dann? Es gibt genau drei Wege, mit einem Teilfehler umzugehen. Alle drei sind Arbeit, keiner ist magisch. Aber sie sind ehrlich, und ehrlich schlägt magisch, wenn Geld und Kundenvertrauen im Spiel sind.

Vorwärts reparieren. Sie versuchen den gescheiterten Schritt so lange erneut, bis er klappt. Das ERP war vierzig Sekunden weg? Dann versuchen Sie es in zwei Minuten wieder, und in fünf, und in zwanzig. Für einen kurzen Ausfall ist das der beste Weg, weil am Ende genau das passiert, was passieren sollte, nur später. Der Haken: Der Schritt muss wiederholbar sein, ohne beim zweiten Mal Unsinn zu bauen. Dazu gleich mehr.

Rückwärts ausgleichen. Wenn der Prozess nicht sinnvoll fertig werden kann, machen Sie das Geschehene aktiv rückgängig, nicht durch ein Rollback, sondern durch eine Gegenbuchung. Die Karte wurde belastet, aber die Bestellung scheitert dauerhaft? Dann erstatten Sie das Geld. Nicht "als wäre nichts gewesen", sondern als eigener, sichtbarer Vorgang: Belastung, dann Erstattung. Das ist der Kern dessen, was Entwickler eine Kompensation nennen.

Von Hand abgleichen. Manchmal ist der halbe Zustand zu heikel, um ihn automatisch aufzulösen. Dann ist der richtige Schritt, einen Menschen zu holen. Nicht als Eingeständnis des Scheiterns, sondern als bewusste Entscheidung: Dieser Fall ist selten und teuer genug, dass ein Mensch draufschauen soll. Der Trick ist, dass der Mensch überhaupt erfährt, dass es diesen Fall gibt. Dazu braucht es einen Ort, an dem gescheiterte Vorgänge landen, statt lautlos zu verschwinden.

In der Realität kombinieren Sie diese drei. Erst ein paar automatische Versuche vorwärts. Wenn das nichts wird, entweder eine Kompensation oder ein Ticket für einen Menschen. Was Sie nie tun sollten: so tun, als gäbe es einen vierten Weg, der alles sauber verschwinden lässt. Den gibt es nicht.

Kompensation ist kein Rückgängigmachen

Der wichtigste Gedankensprung ist dieser: Eine Kompensation stellt nicht den alten Zustand her. Sie fügt einen neuen Schritt hinzu, der die Wirkung des alten neutralisiert.

Das klingt nach Haarspalterei, ist aber der ganze Unterschied. Wenn Sie eine Rechnung storniert haben, ist die Rechnung nicht verschwunden. Es gibt sie weiter, plus eine Stornorechnung. Ihr Steuerberater will genau das so. Wenn Sie eine versehentlich verschickte Bestätigungsmail "zurückholen" wollen, können Sie das nicht. Was Sie tun können, ist eine zweite Mail schicken: "Bitte ignorieren Sie unsere vorige Nachricht." Die erste Mail bleibt in fremden Postfächern. Sie können sie nur einordnen, nicht löschen.

Diese Denkweise verändert, wie Sie Automatisierungen bauen. Für jeden Schritt mit Außenwirkung sollten Sie vorher wissen: Was ist die Gegenbuchung? Karte belasten hat eine Gegenbuchung, nämlich Erstattung. Lagerbestand reduzieren hat eine, nämlich wieder erhöhen. Bestätigungsmail senden hat keine saubere Gegenbuchung, nur ein Nachfassen. Und manche Schritte haben gar keine. Wenn Ihre Automatisierung einen Kunden über eine Preiserhöhung informiert hat, gibt es keine Gegenbuchung. Der Kunde weiß es jetzt.

Diese letzte Kategorie ist die interessante. Schritte, die sich nicht ausgleichen lassen, sind die gefährlichen. Und das führt direkt zur wichtigsten Bautechnik überhaupt.

Die Reihenfolge entscheidet über den Schaden

Wenn Sie akzeptieren, dass jeder Schritt einzeln committet und manche sich nicht zurücknehmen lassen, dann ist die Reihenfolge der Schritte keine Kosmetik mehr. Sie entscheidet, wie schlimm ein Teilfehler wird.

Die Regel ist simpel: Machen Sie die billigen, internen, umkehrbaren Dinge zuerst. Heben Sie die teuren, externen, unumkehrbaren bis zum Schluss auf. Je später ein Schritt steht, desto sicherer sind Sie, dass alles davor geklappt hat, bevor Sie etwas tun, das sich nicht mehr zurücknehmen lässt.

Zurück zum Onlinehändler. Die ursprüngliche Reihenfolge war: Karte belasten, dann Bestellung anlegen, dann Lager, dann Versand, dann Mail. Das Teuerste und Unumkehrbarste, die Kartenbelastung, stand ganz vorne. Genau der schlechteste Platz. Denn wenn irgendetwas danach schiefgeht, haben Sie schon Geld genommen.

Wir haben es umgedreht. Zuerst alle internen Prüfungen und Anlagen: Ist der Kunde valide, ist die Ware da, lässt sich die Bestellung im ERP als Entwurf anlegen. Das sind alles Schritte, die man folgenlos wiederholen oder verwerfen kann. Erst wenn all das steht, kommt der eine unumkehrbare Schritt, die Zahlung. Und danach nur noch Dinge, die selbst bei einem Fehler harmlos nachzuholen sind, wie die Bestätigungsmail.

Diesen einen Punkt, an dem aus "kann ich noch abbrechen" ein "jetzt ist es passiert" wird, nennen wir den Commit-Punkt. Jede mehrstufige Automatisierung mit Außenwirkung hat einen. Die Kunst ist, ihn zu kennen, ihn möglichst spät zu setzen und dahinter nur noch Dinge zu tun, deren Scheitern man verkraften kann. Wer seinen Commit-Punkt nicht benennen kann, hat keine Fehlerbehandlung, sondern nur Glück gehabt.

Idempotenz: der zweite Versuch darf nicht doppelt buchen

Vorwärts reparieren klingt einfach: einfach nochmal versuchen. Der Teufel steckt darin, dass "nochmal versuchen" gefährlich ist, wenn der erste Versuch teilweise durchkam.

Stellen Sie sich vor, der Schritt "Karte belasten" läuft, das Geld wird gebucht, aber die Bestätigung des Zahlungsdienstleisters geht auf dem Rückweg verloren. Ihre Automatisierung denkt, der Schritt sei gescheitert, und versucht es nochmal. Jetzt haben Sie zweimal belastet. Der Kunde zahlt doppelt für eine einzige Bestellung. Das ist kein theoretisches Risiko, das passiert regelmäßig, gerade bei wackligen Verbindungen.

Die Lösung heißt Idempotenz, ein sperriges Wort für eine einfache Eigenschaft: Ein Schritt, den Sie zweimal ausführen, hat dieselbe Wirkung wie einmal. Die meisten guten Zahlungsdienstleister bieten dafür einen Idempotenzschlüssel an. Sie schicken bei jeder Belastung eine eindeutige Kennung mit, etwa die Bestellnummer. Kommt dieselbe Kennung ein zweites Mal, erkennt der Dienstleister sie und bucht nicht erneut, sondern gibt Ihnen das Ergebnis des ersten Versuchs zurück. Zwei Versuche, eine Buchung.

Nicht jedes System bietet solche Schlüssel. Dann müssen Sie die Prüfung selbst bauen: Bevor Sie eine Bestellung anlegen, schauen Sie nach, ob es schon eine mit dieser Nummer gibt. Bevor Sie eine Mail schicken, prüfen Sie ein Feld, ob sie schon raus ist. Das ist mehr Arbeit, aber es ist der Unterschied zwischen einer Automatisierung, die man gefahrlos nochmal anstoßen kann, und einer, bei der jeder Neustart russisches Roulette ist.

Als Faustregel: Jeder Schritt, der etwas in einem fremden System verändert, sollte idempotent sein, oder Sie sollten sehr genau wissen, warum nicht. Ohne Idempotenz ist die Strategie "vorwärts reparieren" nicht sicherer als gar keine, sondern nur schneller im Anrichten von Schaden.

Zwischenstände speichern, damit man weiß, wie weit man kam

Es gibt noch ein Problem beim Wiederholen: Woher weiß der zweite Versuch, wo der erste stehen geblieben ist? Wenn Sie eine fünfstufige Automatisierung komplett von vorne starten, laufen die ersten Schritte erneut, auch die, die beim ersten Mal schon geklappt haben. Ohne Idempotenz ist das eine Katastrophe. Mit Idempotenz ist es verschwenderisch, aber okay.

Sauberer ist, sich zu merken, wie weit man gekommen ist. In der Praxis heißt das: Der bearbeitete Datensatz bekommt ein Statusfeld. Nach Schritt zwei steht dort "im ERP angelegt", nach Schritt vier "versandbereit". Bricht die Automatisierung ab und läuft später erneut, schaut sie zuerst auf diesen Status und überspringt, was schon erledigt ist. Sie steigt dort ein, wo sie aufgehört hat.

Das kostet ein Feld und ein bisschen Disziplin, und es macht den Unterschied zwischen einem Prozess, den man beliebig oft neu anstoßen kann, und einem, bei dem man vorher lange grübeln muss, was wohl schon passiert ist. Gerade bei langlaufenden Abläufen, die auf eine Freigabe oder eine externe Antwort warten, ist so ein Status keine Kür, sondern die einzige Möglichkeit, den Prozess nach einer Unterbrechung sauber fortzusetzen.

Wiederholen mit Verstand, nicht mit der Brechstange

Vorwärts reparieren steht und fällt damit, wie Sie wiederholen. Der naive Reflex ist, sofort und immer wieder zu versuchen. Genau das macht es schlimmer. Wenn ein fremdes System gerade überlastet ist und Sie es im Sekundentakt anschießen, halten Sie es unten. Sie werden Teil des Problems, nicht der Lösung.

Wir arbeiten mit wachsenden Abständen. Der erste erneute Versuch kommt nach ein, zwei Minuten, der nächste nach fünf, dann nach zwanzig, dann nach einer Stunde. Ein kurzes Zucken der Gegenseite ist meist nach dem zweiten Versuch vorbei. Ein längerer Ausfall wird ausgesessen, ohne dass Ihr Ablauf hundert sinnlose Anfragen produziert. Ein kleiner Zufallsanteil bei den Abständen hilft zusätzlich, damit nicht alle wartenden Vorgänge exakt gleichzeitig wieder losstürmen und die Gegenseite erneut umwerfen.

Genauso wichtig ist eine Obergrenze. Nach einer festgelegten Zahl von Versuchen, oder nach einer festgelegten Zeit, hört die Automatisierung auf, es allein zu versuchen. Ein Vorgang, der seit sechs Stunden bei jedem Versuch scheitert, wird beim siebenundzwanzigsten nicht plötzlich klappen. Er gehört dann in die Fehlerablage, zu einem Menschen. Ohne diese Grenze bauen Sie sich einen Vorgang, der ewig im Kreis läuft und dabei entweder Kosten produziert oder unbemerkt feststeckt.

Und Sie müssen unterscheiden, welche Fehler ein Wiederholen überhaupt verdienen. Eine Zeitüberschreitung oder ein "Service gerade nicht verfügbar" ist vorübergehend, da lohnt der zweite Versuch. Eine abgelehnte Kreditkarte, eine ungültige Adresse, ein "diesen Kunden gibt es nicht" ist dauerhaft. Solche Fehler hundertmal zu wiederholen ändert nichts, außer dass Sie hundertmal dieselbe Absage bekommen. Der Fehlerzweig muss diese beiden Sorten auseinanderhalten und nur die vorübergehenden in die Warteschlange schicken. Die dauerhaften gehen direkt zur Kompensation oder zum Menschen.

Wie das Ganze in Make oder n8n aussieht

Das klingt nach viel Theorie, wird aber sehr konkret, sobald man es baut. So sieht ein belastbarer mehrstufiger Ablauf bei uns typischerweise aus:

Am Anfang steht ein eindeutiger Schlüssel für den Vorgang, meist eine Kombination aus Quelle und einer ID, etwa die Bestellnummer. Dieser Schlüssel begleitet den Vorgang durch alle Schritte und landet in jedem Log. Wenn drei Wochen später jemand fragt, was mit Bestellung 10453 passiert ist, findet man mit diesem einen Schlüssel jeden Schritt wieder.

Dann kommen die internen, umkehrbaren Schritte, sortiert vor den Commit-Punkt. Jeder schreibt seinen Fortschritt in ein Statusfeld auf dem Datensatz. Der eine unumkehrbare Schritt, in unserem Beispiel die Zahlung, wird mit einem Idempotenzschlüssel abgesichert.

Jeder Schritt hat einen Fehlerzweig. Und dieser Zweig tut nicht einfach nichts. Er entscheidet: War der Fehler vorübergehend, etwa eine Zeitüberschreitung? Dann in die Warteschlange für einen erneuten Versuch. War er dauerhaft, etwa eine abgelehnte Karte? Dann, je nach Schritt, entweder eine Kompensation auslösen oder den Vorgang in eine Liste "braucht einen Menschen" legen.

Diese Liste ist der wichtigste und meistvergessene Teil. Nennen Sie sie Fehlerablage, Dead-Letter-Ablage, egal. Entscheidend ist, dass gescheiterte Vorgänge dort sichtbar liegen, mit Schlüssel, letztem Status und Fehlermeldung. Ein Mensch schaut einmal am Tag drauf. In den meisten Wochen ist die Liste leer. An dem einen schlechten Tag ist sie der Grund, warum aus einem Fehler kein Kundenverlust wird.

Was wir bewusst nicht bauen, ist der Versuch, jede erdenkliche Kompensation zu automatisieren. Für häufige, klar definierte Fälle, ja. Für seltene, verzwickte Fälle ist ein Mensch mit der richtigen Information schneller und sicherer als ein Automatismus, den niemand je unter Realbedingungen getestet hat. Automatisierung heißt nicht, dass am Ende kein Mensch mehr vorkommt. Es heißt, dass der Mensch nur noch die Fälle sieht, die wirklich ein Urteil brauchen.

Die unbequeme Wahrheit über verteilte Zustände

Es gibt einen Punkt, an dem auch die beste Bautechnik endet. Sobald zwei Systeme unabhängig voneinander Daten halten, die dasselbe beschreiben sollen, können sie auseinanderdriften. Nicht weil jemand einen Fehler gemacht hat, sondern weil sie eben zwei Systeme sind. Ein Netzwerk zwischen ihnen kann in jedem Moment ausfallen, und dann weiß das eine System schon etwas, das das andere noch nicht weiß.

Die Informatik hat das vor Jahrzehnten festgehalten: Sobald Systeme über ein Netzwerk verbunden sind, das ausfallen kann, müssen Sie sich entscheiden, was Ihnen wichtiger ist, wenn es ausfällt. Sie können nicht gleichzeitig garantieren, dass immer eine Antwort kommt und dass diese Antwort überall dieselbe ist. Für unseren Alltag heißt das schlicht: Ein bisschen Widerspruch zwischen Systemen ist kein Bug, den man wegprogrammieren kann. Es ist ein Zustand, den man managen muss.

Deshalb gehört zu jeder ernsthaften Automatisierungslandschaft ein regelmäßiger Abgleich. Einmal am Tag, oder einmal die Stunde, läuft ein Prozess, der die beiden Datenbestände vergleicht und Abweichungen meldet. Zahlungen ohne Bestellung. Bestellungen ohne Zahlung. Kontakte, die im einen System gelöscht, im anderen aktiv sind. Nicht um Panik zu machen, sondern um die kleinen Widersprüche zu finden, solange sie klein sind. Der Onlinehändler von oben hat heute so einen Abgleich. Er findet im Schnitt ein, zwei Fälle pro Woche, meistens harmlos. Aber er findet sie, statt dass ein Kunde sie findet.

Was das für Ihre Automatisierungen heißt

Wenn Sie einen mehrstufigen Ablauf betreiben, der in fremde Systeme schreibt, lohnt sich ein ehrlicher Blick. Nicht auf die Frage "läuft es?", sondern auf die Frage "was passiert, wenn Schritt drei von fünf abbricht?". Drei Dinge sagen Ihnen, ob der Prozess belastbar ist.

Erstens: Kennen Sie Ihren Commit-Punkt? Wissen Sie, ab welchem Schritt sich der Vorgang nicht mehr folgenlos abbrechen lässt, und steht dieser Schritt so spät wie möglich?

Zweitens: Sind die Schritte mit Außenwirkung idempotent? Können Sie den Ablauf gefahrlos ein zweites Mal anstoßen, ohne dass jemand doppelt belastet oder doppelt benachrichtigt wird?

Drittens: Wo landen die Fälle, die scheitern? Gibt es eine sichtbare Ablage und einen Menschen, der einmal am Tag draufschaut, oder verschwinden Fehler in einem Log, das niemand liest?

Diese drei Fragen entscheiden mehr über die Zuverlässigkeit einer Automatisierung als die Wahl der Plattform. Ein sauber gedachter Ablauf auf einem simplen Werkzeug schlägt einen sorglos gebauten auf dem teuersten. Rollback werden Sie nie bekommen, nicht über fremde Systeme hinweg. Aber Sie können bauen, dass ein Teilfehler kein Drama ist, sondern ein Vorgang, der entweder von selbst wieder gerade gerückt wird oder sichtbar auf dem Tisch eines Menschen landet.

Wenn Sie unsicher sind, wie Ihre bestehenden Automatisierungen mit einem Abbruch mittendrin umgehen, schauen wir gemeinsam drauf. Unser kostenloser Automations-Check geht Ihre wichtigsten Abläufe durch und markiert die Stellen, an denen ein halber Fehler heute unbemerkt teuer werden könnte. Oft sind es zwei, drei Schritte, deren Reihenfolge oder Absicherung den ganzen Unterschied macht.