Der Unterschied zwischen Demo und Produktion
In der Demo läuft der Workflow durch: Anfrage rein, drei Schritte, Ergebnis raus. In der Produktion sieht die Welt anders aus. Zwischen Schritt zwei und drei wird der Server neu gestartet. Ein externer Dienst antwortet nach 30 Sekunden nicht. Dieselbe eingehende Nachricht wird aus Versehen zweimal zugestellt. Wer diese Fälle nicht von Anfang an mitdenkt, baut einen Workflow, der in der Demo glänzt und im Betrieb reihenweise Fehler produziert.
Dieser Beitrag behandelt die drei Eigenschaften, die einen mehrstufigen Workflow produktionsreif machen: Crash-Resume, Timeout-Handling und Idempotenz.
Crash-Resume: nach dem Absturz weitermachen, nicht neu anfangen
Ein mehrstufiger Workflow — Anfrage klassifizieren, Daten anreichern, Entwurf erstellen, zur Freigabe legen — kann Minuten laufen und mehrere externe Aufrufe enthalten. Stürzt der Prozess in Schritt drei ab, darf er nach dem Neustart nicht bei Schritt eins beginnen. Sonst wird der Kontakt zweimal angereichert, die Mail zweimal entworfen.
Die Lösung ist persistenter Zustand pro Schritt. Jeder abgeschlossene Schritt wird dauerhaft festgehalten — welcher Schritt, mit welchem Ergebnis. Nach einem Neustart schaut die Engine nach, was zuletzt erfolgreich war, und setzt exakt dort fort. Der Workflow wird dadurch von einer flüchtigen Ausführung zu einem wiederaufnehmbaren Vorgang.
Timeout-Handling: Warten ist ein Zustand, kein Hängen
Viele Workflow-Schritte warten auf etwas: die Antwort eines externen Dienstes, eine menschliche Freigabe, das Ende einer Bedenkzeit. Ein naiver Workflow blockiert dabei — und wenn die Antwort nie kommt, hängt er für immer.
Ein robuster Workflow behandelt Warten als expliziten Zustand mit einem Timeout:
- Externer Dienst antwortet nicht innerhalb X Sekunden? Definierte Reaktion — erneuter Versuch, Fallback oder Eskalation.
- Menschliche Freigabe kommt nicht innerhalb X Stunden? Eskalation an eine zweite Person, nie stilles Versanden.
- Bedenkzeit (etwa ein Cooldown vor der nächsten Aktion) läuft ab? Geplanter Weckruf, kein aktives Blockieren.
Entscheidend: Wartende Workflows dürfen keine Ressourcen dauerblockieren. Sie legen sich schlafen und werden zum richtigen Zeitpunkt wieder aufgeweckt.
Idempotenz: derselbe Auslöser darf nicht doppelt wirken
In verteilten Systemen kommt es vor, dass ein Auslöser doppelt ankommt — ein Webhook wird wiederholt zugestellt, eine Nachricht doppelt verarbeitet. Ohne Vorkehrung bedeutet das: zwei Angebote statt einem, zwei Mails an denselben Kunden.
Die Gegenmaßnahme heißt Idempotenz: Dieselbe Operation mit demselben Auslöser darf, egal wie oft sie ausgeführt wird, nur einmal wirken. Praktisch erreicht man das über einen Idempotenz-Schlüssel — eine eindeutige Kennung des Auslösers. Bevor ein Schritt wirkt, prüft er: Habe ich diesen Schlüssel schon gesehen? Wenn ja, überspringe ich. Aus "zweimal zugestellt" wird "einmal gewirkt".
Das Zusammenspiel mit menschlichen Freigaben
Diese drei Eigenschaften harmonieren mit Human-in-the-Loop. Eine ausstehende Freigabe ist schlicht ein wartender Workflow-Zustand mit Timeout. Der Workflow pausiert, hält seinen Zustand persistent, und nimmt nach der Freigabe genau dort wieder auf. Crash-Resume sorgt dafür, dass eine Freigabe auch einen Server-Neustart übersteht — die freigegebene Aktion geht nicht verloren, und sie wird auch nicht doppelt ausgeführt.
Häufige Fehler
- Zustand nur im Speicher. Wer den Fortschritt nur im RAM hält, verliert ihn beim Neustart. Zustand gehört persistiert.
- Kein Timeout auf externe Aufrufe. Ein hängender Fremddienst legt sonst den ganzen Workflow lahm.
- Keine Idempotenz bei Auslösern. Doppelte Zustellungen sind kein Randfall, sondern Alltag.
- Freigaben ohne Ablauf. Eine Freigabe, die niemand erteilt und die niemand erinnert, ist ein stiller Prozess-Stillstand.
Fazit
Der Unterschied zwischen einem Demo-Workflow und einem produktionsreifen liegt nicht in der Zahl der Schritte, sondern in drei Eigenschaften: Crash-Resume, damit ein Absturz den Fortschritt nicht vernichtet; Timeout-Handling, damit Warten kein Hängen wird; und Idempotenz, damit ein doppelter Auslöser nicht doppelt wirkt. Wer diese drei von Anfang an mitbaut — statt sie nach dem ersten Produktionsvorfall nachzurüsten — bekommt Automatisierungen, die im echten Betrieb halten, auch neben menschlichen Freigaben und flatterigen Fremddiensten.