Im Maschinenraum ist heute dieser besondere Moment eingetreten: Ein Ablauf ist nicht einfach umgefallen. Er hat sich umgedreht, die Mütze gezogen und angefangen, seine eigenen Spuren aufzuräumen. Das klingt erst nach ordentlicher Erziehung für Cronjobs. In Wahrheit ist es Infrastruktur, die gelernt hat, dass „fehlgeschlagen“ nicht dasselbe ist wie „alles liegt jetzt im Flur“.
Anlass ist Cloudflares Ankündigung zu Saga-Rollbacks für Workflows. Laut Cloudflare können Entwicklerinnen und Entwickler bei step.do() nun Kompensationslogik mitgeben, die ausgeführt wird, wenn ein mehrstufiger Workflow am Ende scheitert. Nicht jedes Zwischenergebnis lässt sich technisch zurückspulen wie ein Kassettendeck. Manchmal muss man eine zweite, gegenteilige Operation auslösen: Geld zurückbuchen, Reservierung lösen, Akte wieder in den Schrank schieben. Nur eben mit weniger Amtsstaub, wenn alles gut geht.
Der Fehler bekommt einen Rückwärtsgang
Das hübsch Gemeine an solchen Abläufen: Schritt eins kann längst draußen in der Welt etwas verändert haben, während Schritt zwei beleidigt in die Ecke fällt. Cloudflare beschreibt dafür das klassische Beispiel einer Überweisung zwischen zwei Banken. Ist die Abbuchung schon durch, aber die Gutschrift scheitert, hilft kein philosophisches „Undo“. Dann braucht es eine neue, saubere Gegenbuchung. In der Werkstatt heißt das: Der Greifarm hat die falsche Kiste schon in Regal B gestellt, also muss ein anderer Greifarm sie wieder herausfummeln. Mit Protokoll. Mit Handschuhen. Möglichst ohne den halben Flur mitzunehmen.
Die Saga-Idee ist alt genug, um in manchen Architekturschränken schon Patina angesetzt zu haben. Neu ist hier die Art, wie Cloudflare sie direkt in Workflows gießt: Rollback-Handler hängen am Schritt, laufen beim terminalen Scheitern in umgekehrter Startreihenfolge und sollen selbst idempotent sein. Dieses Wort steht im Serverraum ungefähr für: „Wenn du denselben Besen zweimal schwenkst, darf danach nicht plötzlich die Werkbank fehlen.“
Nicht jeder Stolperer ist gleich Katastrophe
Interessant ist die kleine Kante im Detail. Ein einzelner Step-Fehler löst nicht automatisch den großen Rückwärtsmarsch aus, wenn der Code den Fehler auffängt und weiterarbeitet. Rollback beginnt erst, wenn der Workflow insgesamt endgültig scheitert. Das ist vernünftig und trotzdem leicht zu übersehen, besonders in Teams, in denen Fehlerbehandlung gern aussieht wie ein sehr müder Praktikant mit einem großen try-Eimer.
Außerdem kann sogar ein fehlgeschlagener Schritt rollbackfähig sein, wenn er vorher schon außen etwas angerempelt hat. Cloudflare weist darauf hin, dass der Rollback-Handler dann auch mit fehlendem Output umgehen können muss. Das ist der Moment, in dem die Maschine sagt: „Ich weiß nicht mehr genau, welche Schraube ich verloren habe, aber ich habe definitiv etwas klappern hören.“
Blechpresse-Befund
Für die Blechpresse ist das kein Glamourthema. Keine Bühne, kein Konfetti, keine neue Superintelligenz mit Pressefoto. Es ist nützlicher: eine kleine Vorrichtung gegen die Sorte Chaos, die moderne Automatisierung sonst gern im Produktionsregal hinterlässt. Je mehr Agenten, APIs und Zahlungskästchen aneinandergekettet werden, desto wichtiger wird nicht nur, dass Schritte laufen. Wichtig ist auch, dass sie würdevoll zurücktreten können, wenn die Realität wieder einmal mit öligen Fingern am Kabel zieht.
Man kann darüber lachen, weil Rückwärtsgänge in Software immer ein bisschen wie Wunschdenken klingen. Aber gerade darum sind sie gut. Nicht als Zauberknopf, sondern als ausdrücklich gebauter Gegenweg. Ein Workflow ohne Kompensationslogik ist wie ein Gabelstapler ohne Bremse: beeindruckend dynamisch, bis jemand fragt, warum die Buchhaltung im Warenausgang liegt.
Quellenkasten
Faktenbasis: Cloudflare beschreibt die Einführung von Saga-Rollbacks für Cloudflare Workflows, inklusive step.do()-Rollback-Handlern, umgekehrter Ausführungsreihenfolge, terminalem Scheitern und Idempotenz-Hinweisen im Beitrag „How we built saga rollbacks for Cloudflare Workflows“ vom 25. Juni 2026.