Hinter dem schwierigen Zweig steckt meist eine Fachregel
Ein Workflow wiederholt eine Bestelländerung nach einem Timeout. Das Zielsystem hat sie bereits angenommen, der Workflow weiss es nur nicht. Ein weiterer Knoten beantwortet die entscheidende Frage nicht: Erzeugt der nächste Versuch eine Dublette? Diese Frage gehört zum Geschäftsvorgang, unabhängig vom Werkzeug für die Ablaufdarstellung.
Für eigenen Code ist die Zahl der Knoten kein brauchbares Kriterium. Entscheidend ist, ob sich das Versprechen eines Vorgangs erklären lässt, ohne den gesamten Workflow zu öffnen. Welche Eingaben gelten, was wird verändert und welcher Zustand überlebt einen Neustart? Wer verantwortet das Ergebnis, wenn der Aufrufer nicht mehr wartet? Daraus entsteht eine sinnvolle Dienstgrenze.
Die Koordination darf sichtbar bleiben
Visuelle Workflows eignen sich für Weiterleitung, Benachrichtigungen, Zeitpläne und die Abstimmung zwischen Systemen. Das Betriebsteam kann den vorgesehenen Ablauf nachvollziehen und erkennen, wo ein Fall stehen geblieben ist. Eine Sammlung kleiner Dienste kann diese Übersicht verschlechtern, besonders wenn deren Betrieb niemand verantwortet.
Kapazität ist eine eigene Entscheidung. n8n beschreibt einen Queue-Modus mit Redis und Worker-Prozessen. Mehr Ausführungskapazität zu benötigen bedeutet deshalb nicht automatisch, dass der Ablauf neu geschrieben werden muss. Das erläutert die aktuelle Dokumentation zum Queue-Modus.
Ein beispielhafter Retourenprozess verdeutlicht die Grenze. Anfrage annehmen, Bestelldaten holen und das Ergebnis weiterleiten kann im Workflow bleiben. Die Entscheidung über die Zulässigkeit der Retoure braucht dagegen eine verantwortliche Stelle und einen prüfbaren Vertrag. Diese Entscheidung auszulagern kann den Ablauf vereinfachen, ohne seinen betrieblichen Nutzen zu verlieren.
Ein Versprechen auslagern, keinen unordentlichen Ausschnitt
Ein sinnvoller Dienst erhält einen fachlichen Auftrag, etwa eine Retoure zu prüfen. Er nimmt nicht einfach einen Sack beliebiger Workflow-Variablen entgegen. Seine Antwort unterscheidet Zustimmung, Ablehnung und fehlende Nachweise. Pflichtfelder und die verwendete Regelversion sind eindeutig.
Tests sollten Streitfälle abbilden: eine teilweise erstattete Bestellung, einen bereits umgetauschten Artikel oder eine veraltete Bestellreferenz. Solche Beispiele bleiben verständlich, wenn der Workflow umgebaut wird. Tests an Knotennamen zu binden verlagert die bestehende Brüchigkeit dagegen nur in ein anderes Repository.
Unbequem wird es bei der Verantwortung. Ein Dienst braucht jemanden für Releases, Sicherheitsupdates, Protokolle und Wiederherstellung. Lässt sich niemand benennen, wird aus einem sichtbaren Problem möglicherweise ein unsichtbares. Ein sauber dokumentierter Workflow kann dann vorläufig die vernünftigere Lösung sein.
Dauerhaften Zustand bewusst platzieren
Ein Vorgang, der ein anderes System verändert, sollte vor dem Versand eine stabile Geschäftsreferenz erhalten. Versuch und Ergebnis werden dauerhaft festgehalten. Ist das Ergebnis ungewiss, wird es im Zielsystem abgeglichen. Ein Timeout allein ist kein Beleg dafür, dass nichts passiert ist. Wiederholte Anfragen sollten das vorhandene Ergebnis liefern können, soweit der Vorgang dies zulässt.
Berechtigungen bleiben eng. Der koordinierende Workflow benötigt keinen uneingeschränkten Datenbankzugang, nur weil der ausgelagerte Dienst Daten verwaltet. Eine gemeinsame Referenz in den Protokollen erlaubt dem Support, denselben Fall über beide Komponenten zu verfolgen, ohne vollständige Kundendaten überall abzulegen.
Auch die Migration braucht einen Rückweg. Zunächst lassen sich Entscheidungen ohne externe Schreibvorgänge vergleichen. Abweichungen werden untersucht, bevor der Aufrufer umgestellt wird. Während des Vergleichs dürfen alter und neuer Pfad niemals dieselbe externe Aktion auslösen.
Diese Woche die Grenze prüfen
Den Workflow auswählen, dessen Wiederaufnahme am meisten Unsicherheit auslöst. Unumkehrbare Aktionen, gespeicherten Zustand, Wiederholungsregeln und Zuständigkeit auf einer Seite festhalten. Eine Person aus dem Betrieb sollte damit einen gescheiterten Durchlauf erklären können.
Nur die Regel auslagern, die am bisherigen Ort nicht sauber getestet oder verantwortet werden kann. Eingaben, Ergebnisse und Wiederherstellung werden vor der Framework-Wahl definiert. Die umgebende Koordination bleibt sichtbar. Das Ziel ist ein erklärbarer, sicher fortsetzbarer Fall, nicht eine kleinere Zeichenfläche oder mehr eigener Code.