Warum Ihr Workflow dieselbe Buchung zweimal anlegt
API-Timeout, automatischer Retry, doppelte Buchung im ERP. Das passiert öfter, als man denkt. Es liegt nicht am Code, sondern an einem fehlenden Konzept.
Warum Ihr Workflow dieselbe Buchung zweimal anlegt
Ein Kunde verarbeitet automatisch Eingangsrechnungen. Läuft seit Monaten, ohne Auffälligkeiten. Dann ein API-Timeout bei einem Drittanbieter. Die Plattform startet automatisch einen zweiten Versuch. Die Rechnung wird zweimal gebucht. Der Buchhalter findet es drei Wochen später beim Monatsabschluss.
Das ist kein Programmierungsfehler. Es fehlte ein Konzept: Idempotenz.
Was Idempotenz bedeutet
Der Begriff kommt aus der Mathematik. Eine Operation ist idempotent, wenn sie mehrfach ausgeführt dasselbe Ergebnis liefert wie einmal ausgeführt. f(f(x)) = f(x).
Auf Automatisierungsworkflows übertragen: Ein Webhook, der zweimal ausgelöst wird, sollte einmal das Ergebnis erzeugen, nicht zweimal. Das klingt selbstverständlich. Die meisten Workflows erfüllen es nicht, weil bei der Planung niemand fragt, was passiert, wenn der Prozess ein zweites Mal anläuft.
Wann Workflows öfter laufen, als Sie erwarten
Netzwerk-Timeouts mit automatischem Retry
Zapier, n8n und Make haben eingebaute Wiederholungslogik. Wenn ein Webhook-Empfänger nicht innerhalb eines definierten Zeitfensters antwortet, versucht die Plattform es erneut, manchmal ohne dass es im Log deutlich sichtbar ist. Hat der Workflow bis zum datenschreibenden Schritt funktioniert und greift dann der Retry, hat man das Problem.
n8n wiederholt Webhooks standardmäßig bis zu dreimal. Make kann Szenarien bei bestimmten Fehlercodes automatisch neu starten. Zapier hat eine ähnliche Logik. Das ist meistens eine hilfreiche Funktion. Für nicht-idempotente Workflows ist es ein Risiko.
"At least once delivery" externer APIs
Viele APIs, darunter Stripe, Shopify und HubSpot, garantieren "mindestens einmalige Auslieferung", nicht "genau einmalige". Das steht im Kleingedruckten. Konkret: Stripe kann einen `payment_intent.succeeded`-Event zweimal senden, wenn die Bestätigungsantwort zu spät ankam. Wenn der Workflow dann zweimal eine Bestellung anlegt, ist das kein Fehler der API. Die Dokumentation warnt ausdrücklich davor.
Manuelle Wiederholungen nach Fehler
Der häufigste Fall in der Praxis: Ein Workflow schlägt an Schritt 4 von 6 fehl. Jemand klickt auf "Replay". Der Workflow läuft erneut, aber die Schritte 1 bis 3 haben möglicherweise schon Daten geschrieben. Ergebnis: Teile des Prozesses laufen doppelt, andere nicht. Inkonsistente Zustände, die schwer zu bereinigen sind.
Warum das lange unbemerkt bleibt
Solche Fehler zeigen sich selten sofort. Eine doppelte Buchung fällt beim Monatsabschluss auf. Eine doppelte E-Mail wird vielleicht nie gemeldet, weil der Empfänger davon ausgeht, dass es ein Versehen war. Ein doppelter CRM-Eintrag bleibt wochenlang unentdeckt, bis jemand denselben Kontakt zweimal anruft und sich fragt, warum er zweimal im System steht.
Bis jemand sucht, ist der ursprüngliche Auslöser längst vergessen. Man sieht den falschen Zustand, aber nicht den Moment, der ihn erzeugt hat.
Was das Problem löst
Idempotenz-Schlüssel
Jeder eingehende Event bekommt eine eindeutige ID. Bevor der Workflow etwas schreibt, prüft er: Habe ich diese ID schon verarbeitet? Falls ja, Abbruch. Falls nein, verarbeiten und die ID als erledigt speichern.
Stripe sendet jeden Webhook mit einem `id`-Feld. Shopify ebenfalls. Man speichert verarbeitete IDs in einer Datenbanktabelle oder einem Redis-Key. Vor jedem Schreibvorgang eine Abfrage. Der Code ist kurz. Die Disziplin, ihn konsequent einzubauen, ist der schwierigere Teil.
```javascript if (await db.exists('processed_events', webhookId)) { return { status: 'already_processed' }; } await processWebhook(data); await db.insert('processed_events', webhookId, { processedAt: now() }); ```
Upsert statt Insert
Statt reinem INSERT nimmt man INSERT ... ON CONFLICT DO UPDATE. Kommt derselbe Datensatz zweimal rein, wird er aktualisiert, nicht verdoppelt. Das funktioniert gut für Stammdaten: Kontakte, Produkte, Konfigurationen. Bei Transaktionsdaten, also Buchungen und Bestellungen, reicht Upsert allein nicht, weil die doppelte Anlage fachlich falsch wäre, auch wenn die Werte identisch sind.
Fachliche Duplikatsprüfung
Statt auf technische IDs zu verlassen: prüfen, ob ein inhaltlich identischer Datensatz schon existiert. "Bestellung X von Kunde Y wurde heute schon angelegt" als Abfrage vor dem Schreiben. Mehr Aufwand, aber robuster in Szenarien, in denen die technische Event-ID variiert.
Welche Workflows das wirklich brauchen
Nicht jeder Workflow muss idempotent sein. Ein Slack-Ping, das zweimal kommt, ist kein Problem. Eine Buchung, eine Bestellung, ein Vertrag: da gehört Idempotenz rein.
Die Frage, die ich bei jedem datenschreibenden Workflow stelle: Was passiert, wenn dieser Schritt zweimal ausgeführt wird? Wenn die Antwort "dasselbe wie einmal" lautet, passt es. Wenn die Antwort "ich weiß nicht" ist, gibt es Arbeit.
Wie Sie bestehende Workflows prüfen
Fragen, die ich als Startpunkt stelle:
Welche Workflows schreiben Daten in ein produktives System? Welche dieser Workflows werden von externen Quellen mit Retry-Logik oder "at least once"-Semantik ausgelöst? Und: Wenn ein solcher Workflow zweimal läuft, gibt es eine Prüfung, die das abfängt?
Wo die Antwort auf die letzte Frage "nein" ist, lohnt sich Nachbesserung. Bei niedrigem Volumen bleiben diese Fehler oft verborgen. Bei höherem Volumen tauchen sie regelmäßig auf, und die Bereinigung kostet dann mehr als die Prävention.
Den kostenlosen Automations-Check nutzen viele Kunden als Einstieg, um genau das zu durchleuchten, in etwa 30 Minuten.