Doppelte Verarbeitung in Automationen schnell verhindern

Ein kurzer Delay verhindert keine doppelte Verarbeitung. Er verschiebt den zweiten Lauf lediglich um ein paar Sekunden und vermittelt dabei ein beruhigendes Gefühl, das ungefähr bis zum nächsten Supportfall hält. Zuverlässig wird die Automation erst, wenn sie einen bereits bekannten Vorgang eindeutig erkennt und kontrolliert beendet.

Dieses Verhalten heißt Idempotenz: Derselbe Vorgang darf mehrfach angestoßen werden, erzeugt aber nur einmal die beabsichtigte Wirkung. Für bestehende Automationen brauchst du dafür häufig keinen kompletten Umbau. Der wirksamste schnelle Fix besteht aus einem stabilen Ereignisschlüssel und einem kleinen Verarbeitungsprotokoll.

Zuerst klären: Ist es wirklich derselbe Vorgang?

Ähnliche Inhalte sind noch kein Beweis für eine doppelte Verarbeitung. Zwei Personen können dasselbe Formular mit identischen Angaben absenden. Ein Datensatz kann außerdem mehrfach aktualisiert werden, obwohl jede Änderung fachlich relevant ist.

Prüfe deshalb die eingehenden Daten oder vorhandenen Logs. Entscheidend ist eine Kennung aus dem auslösenden System, zum Beispiel eine Übermittlungs-ID, eine Webhook-ID, eine Bestellnummer oder die ID eines Queue-Jobs. Daraus ergeben sich zwei unterschiedliche Fälle:

• Dieselbe Quell-ID trifft mehrfach ein: Die Quelle wiederholt dasselbe Ereignis, etwa nach einem Timeout oder einem Retry.
• Unterschiedliche Quell-IDs enthalten ähnliche Daten: Es liegen wahrscheinlich mehrere eigenständige Ereignisse vor. Hier wäre eine pauschale Zusammenführung riskant.

Ein Hash aus Name, E-Mail-Adresse und Nachrichtentext wirkt zunächst praktisch, kann aber zwei legitime Anfragen zusammenwerfen. Verwende Inhaltsvergleiche daher nur, wenn das Quellsystem wirklich keine brauchbare Kennung liefert und du die fachlichen Folgen geprüft hast.

Der schnelle Fix: Ereignisschlüssel vor der Aktion reservieren

Der Ereignisschlüssel ist eine eindeutige Zeichenfolge für genau den Vorgang, den deine Automation einmal verarbeiten soll. Eine geeignete Form wäre beispielsweise kontaktformular:übermittlung:98421. Enthält die Automation mehrere Ereignisarten, gehört auch die Art in den Schlüssel. Eine reine Datensatz-ID reicht dann nicht, weil das Anlegen und eine spätere Aktualisierung sonst fälschlich als dasselbe Ereignis gelten könnten.

Speichere diesen Schlüssel, bevor die Automation eine Aufgabe anlegt, eine Nachricht verschickt oder einen Datensatz erzeugt. Der Ablauf sieht so aus:

1. Die Automation empfängt das Ereignis.
2. Sie bildet aus den Quelldaten einen stabilen Ereignisschlüssel.
3. Sie versucht, diesen Schlüssel mit dem Status in Bearbeitung zu speichern.
4. Existiert der Schlüssel bereits, wird keine neue fachliche Aktion ausgeführt.
5. Nach erfolgreicher Verarbeitung wechselt der Status auf abgeschlossen.
6. Bei einem Fehler wird der Status zusammen mit der Fehlermeldung aktualisiert.

Dieses kleine Register kann eine Datenbanktabelle, der Datenspeicher einer Automationsplattform oder ein eindeutiges Feld im Zielsystem sein. Wichtig ist weniger das Werkzeug als die Garantie, dass derselbe Schlüssel nur einmal angelegt werden kann.

Warum „erst suchen, dann anlegen“ eine Lücke lässt

Viele schnelle Automationen prüfen zunächst, ob ein Schlüssel vorhanden ist, und legen ihn anschließend an. Das funktioniert bei nacheinander eintreffenden Aufrufen. Starten zwei Läufe nahezu gleichzeitig, können jedoch beide dieselbe Prüfung bestehen. Danach führen beide die Aktion aus.

Die Reservierung sollte deshalb atomar erfolgen. Atomar bedeutet hier, dass Prüfung und Anlage als ein unteilbarer Vorgang behandelt werden. In einer Datenbank erreichst du das typischerweise mit einer eindeutigen Einschränkung auf der Schlüsselspalte. Der erste Lauf legt den Schlüssel an, der zweite erhält einen Konflikt und beendet sich.

Bei einer Automationsplattform solltest du prüfen, ob deren Datenspeicher eindeutige Schlüssel oder eine vergleichbare Operation unterstützt. Eine Tabellenkalkulation mit dem Ablauf „Zeile suchen, dann Zeile ergänzen“ ist bei parallelen Läufen keine verlässliche Sperre. Für seltene und unkritische Vorgänge kann sie als Übergang dienen. Bei Rechnungen, Bestellungen oder externen Benachrichtigungen ist sie zu schwach.

Der Status entscheidet über Wiederholungen

Ein bloßer Eintrag „schon gesehen“ verhindert Duplikate, kann aber auch notwendige Wiederholungen blockieren. Bricht die Automation nach der Reservierung ab, bleibt der Vorgang sonst dauerhaft liegen. Verwende deshalb mindestens die Zustände in Bearbeitung, abgeschlossen und fehlgeschlagen.

• In Bearbeitung: Ein anderer Lauf verarbeitet das Ereignis gerade. Ein weiterer Aufruf beendet sich oder versucht es später erneut.
• Abgeschlossen: Die gewünschte Aktion wurde erfolgreich ausgeführt. Weitere Aufrufe dürfen ohne erneute Aktion als erledigt gelten.
• Fehlgeschlagen: Der Lauf ist abgebrochen. Eine definierte Wiederholung oder manuelle Prüfung ist möglich.

Speichere zusätzlich den Zeitpunkt des Starts und eine Referenz auf das erzeugte Zielobjekt, etwa die ID der angelegten Aufgabe. Damit kannst du unterscheiden, ob ein Lauf tatsächlich noch arbeitet oder seit Stunden festhängt. Die Zielreferenz hilft außerdem bei der späteren Fehlersuche und bei kontrollierten Wiederholungen.

Die verbleibende Lücke liegt oft hinter der Automation

Ein schwieriger Fall entsteht, wenn das Zielsystem die Aktion erfolgreich ausführt, deine Automation die Antwort aber nicht mehr erhält. Beim nächsten Versuch steht der Vorgang möglicherweise noch auf in Bearbeitung oder fehlgeschlagen, obwohl die Aufgabe, Buchung oder Nachricht bereits erzeugt wurde.

Prüfe daher zuerst, ob das Zielsystem selbst einen Idempotenzschlüssel akzeptiert. Dann übergibst du deinen Ereignisschlüssel bei jedem Versuch erneut. Das Zielsystem kann Wiederholungen erkennen und dasselbe Ergebnis zurückgeben.

Fehlt diese Funktion, speichere den Quellschlüssel nach Möglichkeit in einem eindeutigen Feld des Zielobjekts. Vor einer Wiederholung sucht die Automation dort nach einem vorhandenen Eintrag. Diese Suche ist als zusätzliche Absicherung sinnvoll, ersetzt aber keine atomare Reservierung am Eingang.

Eine absolute Genau-einmal-Garantie über mehrere unabhängige Systeme hinweg ist oft nicht erreichbar. Praktisch brauchst du deshalb zwei Schutzlinien: Die Automation reserviert den Vorgang eindeutig, und das Zielsystem erhält eine nachvollziehbare Referenz für denselben Vorgang.

So rüstest du eine bestehende Automation nach

Für den Umbau reicht ein klar abgegrenzter Eingriff am Anfang des Workflows. Du musst die nachfolgenden Schritte nicht neu modellieren.

1. Quelle untersuchen: Suche in der eingehenden Nutzlast nach einer stabilen Ereignis- oder Übermittlungs-ID.
2. Gültigkeitsbereich festlegen: Entscheide, ob die ID global eindeutig ist oder mit Quelle und Ereignisart kombiniert werden muss.
3. Register anlegen: Speichere Schlüssel, Status, Startzeit, Abschlusszeit, Fehlermeldung und Zielreferenz.
4. Reservierung vorschalten: Lege den Schlüssel vor jeder fachlichen Aktion eindeutig an.
5. Doppelte Läufe beenden: Behandle einen vorhandenen, abgeschlossenen Schlüssel als erfolgreichen Leerlauf statt als technischen Fehler.
6. Fehlerweg ergänzen: Aktualisiere den Status bei einem Abbruch und definiere, wann ein Retry erlaubt ist.

Falls du keine eigene Datenbank oder keinen geeigneten Datenspeicher hast, kann ein eindeutiges Quellfeld im Zielsystem der pragmatischste Fix sein. Dann versucht die Automation, den Datensatz direkt mit diesem Wert anzulegen. Weist das Zielsystem Duplikate zuverlässig ab, übernimmt es zugleich die Reservierung. Das funktioniert allerdings nur, wenn die Eindeutigkeit dort technisch erzwungen wird.

Vier Tests decken die typischen Fehler ab

Teste den Fix nicht nur mit einem normalen Durchlauf. Die entscheidenden Schwachstellen zeigen sich erst bei Wiederholungen und Abbrüchen.

• Direkte Wiederholung: Sende dasselbe Ereignis zweimal. Die Zielaktion darf nur einmal entstehen.
• Paralleler Start: Starte zwei Verarbeitungen möglichst gleichzeitig. Nur ein Lauf darf den Schlüssel reservieren.
• Fehler vor der Zielaktion: Erzwinge einen Abbruch nach der Reservierung. Der Status muss eine kontrollierte Wiederholung erlauben.
• Fehler nach der Zielaktion: Simuliere einen Verbindungsabbruch nach erfolgreicher Anlage im Zielsystem. Der Retry darf kein zweites Zielobjekt erzeugen.

Kontrolliere dabei sowohl das Verarbeitungsregister als auch das Zielsystem. Ein grüner Automationslauf allein beweist nicht, dass keine doppelten Datensätze entstanden sind.

Wann der kleine Fix nicht mehr reicht

Ein Ereignisschlüssel löst die doppelte Verarbeitung desselben Vorgangs. Er löst keine fachlichen Konflikte zwischen verschiedenen Ereignissen. Wenn etwa zwei Personen denselben Datensatz gleichzeitig ändern, brauchst du Regeln für Versionen, Prioritäten oder Zusammenführung.

Auch eine unzuverlässige Quelle lässt sich damit nicht vollständig reparieren. Fehlt jede stabile Kennung, musst du festlegen, welche Kombination von Merkmalen einen Vorgang repräsentiert und wie lange sie als Duplikat gilt. Diese Entscheidung ist fachlich: Eine identische Supportanfrage nach zwei Minuten kann ein Doppelklick sein, dieselbe Anfrage nach zwei Wochen aber ein berechtigtes Nachhaken.

Für den häufigen Fall mehrfach zugestellter Webhooks, überlappender Zeitpläne oder automatischer Retries bleibt der Ereignisschlüssel jedoch der kleinste belastbare Eingriff. Reserviere ihn vor der ersten Wirkung, erzwinge seine Eindeutigkeit und dokumentiere den Verarbeitungsstatus. Damit wird eine wiederholte Zustellung zu einem harmlosen zweiten Aufruf statt zu einem zweiten Datensatz.