Idempotenz in Automationen: Duplikate verhindern (mit Checkliste)

Warum Idempotenz dein wichtigstes Anti-Chaos-Prinzip ist

Wenn du Automationen baust, passiert früher oder später Folgendes: Ein Event kommt doppelt. Oder ein Schritt läuft zweimal. Oder ein Tool macht einen Retry, weil es dein Timeout als Fehler interpretiert.

Das Ergebnis kennst du vielleicht:

Doppelte Tasks im Projekttool.
Zwei E-Mails an den Kunden.
Zwei Belege im Buchhaltungssystem.
Ein "Status auf Done" wird wieder zurückgedreht, weil ein alter Run nachzieht.

Idempotenz ist die Eigenschaft, die verhindert, dass dich solche Duplikate in den Wahnsinn treiben.

Zur Übersicht: Workflows: Automatisierung

Ziel dieses Artikels

Du lernst:

was "idempotent" in Automationen konkret bedeutet,
warum Duplikate normal sind (und keine Ausnahmen),
wie du mit einem Idempotency Key und einem kleinen Dedupe-Store robuste Workflows baust,
welche typischen Fehler du vermeiden solltest.

Kurzfazit (TL;DR)

Baue jede Automation so, als würde jeder Trigger mindestens einmal kommen - manchmal eben auch zweimal.
Nutze eine stabile Event-ID oder baue einen Idempotency Key, der bei einem Retry exakt gleich bleibt.
Speichere verarbeitete Keys in einem persistenten Dedupe-Store (nicht nur im RAM).
Mache Side-Effects idempotent: lieber Upsert/Update statt blindes Create, und wenn "Create" sein muss, dann mit eindeutigem externen Schlüssel.

Was bedeutet Idempotenz in einfachen Worten

Ein Schritt ist idempotent, wenn er bei Wiederholung denselben Zustand herstellt, ohne "mehr davon" zu erzeugen.

Konkrete Beispiele:

Idempotent: "Setze Ticket-Status auf Done." (Done bleibt Done)
Nicht idempotent: "Erstelle ein Ticket." (zweimal ausführen = zwei Tickets)
Idempotent: "Setze Kunden-Tag 'Bezahlt'." (Tag ist vorhanden oder wird gesetzt)
Nicht idempotent: "Sende E-Mail 'Rechnung bezahlt'." (zweimal ausführen = zwei E-Mails)

Wichtig: Idempotenz ist keine theoretische Perfektion, sondern ein Praxis-Tool gegen Duplikate.

Warum Duplikate in der Praxis ganz normal sind

Die meisten Integrationen sind "at-least-once": Ein Event wird mindestens einmal zugestellt, nicht garantiert genau einmal.

Typische Ursachen:

Retries bei Fehlern: Ein Provider sendet einen Webhook erneut, wenn er kein schnelles 2xx bekommt.
Timeouts: Dein System hat verarbeitet, aber die Antwort kam zu spät. Der Provider geht von "fehlgeschlagen" aus und schickt erneut.
Parallelität: Zwei Worker ziehen denselben Job.
Polling mit Overlaps: Du pollst "seit letzter Stunde", aber die Abfrage überschneidet sich oder updatedAt ist nicht sauber.

Deshalb ist die richtige Haltung: Duplikate sind nicht das Ausnahme-Szenario. Duplikate sind der Normalfall, auf den du vorbereitet sein solltest.

Passender Hintergrund, wenn du Webhooks und Polling einordnen willst: Webhook vs. Polling

Wo du Idempotenz brauchst

In Automationen gibt es drei Stellen, an denen du duplikatsicher werden kannst (und oft auch solltest):

Eingang (Trigger): "Habe ich dieses Event schon gesehen?"
Verarbeitung (Workflow-Schritte): "Kann ich den Schritt gefahrlos wiederholen?"
Ausgang (Side-Effects): "Erzeuge ich bei Wiederholung etwas Neues?"

Wenn du nur eine Stelle stabil machst, dann fast immer den Eingang (Deduplizierung) oder den Side-Effect (Upsert statt Create). Idealerweise beides.

Das Grundmuster: Idempotency Key + Dedupe-Store

Die Idee ist einfach:

Du berechnest für jedes Event einen stabilen Schlüssel (Idempotency Key).
Du speicherst diesen Key beim ersten Mal in einem persistenten Store.
Kommt derselbe Key nochmal, beendest du die Verarbeitung früh oder gibst das bereits bekannte Ergebnis zurück.

Schritt 1: Einen stabilen Idempotency Key wählen

Gute Keys sind:

stabil: beim Retry identisch
eindeutig genug: verhindert Kollisionen
tenant-sicher: wenn du mehrere Kunden/Systeme hast, ist der Kunde Teil des Keys

Beispiele für Key-Quellen:

Webhook mit Event-ID: provider:eventId
Objekt-Update: invoice:12345:updatedAt:2026-01-22T10:00:00Z
Payment: payment:transactionId oder invoice:12345:payment:txn_...

Wenn du keine Event-ID bekommst, baue den Key aus stabilen Feldern. Nimm nicht Dinge wie "aktueller Timestamp" oder "zufällige UUID", sonst ist jeder Retry ein anderer Key.

Security-Note: Wenn Payloads personenbezogene Daten enthalten, speichere nicht die komplette Payload als Key. Nutze lieber IDs oder (wenn es sein muss) einen Hash über einige Felder.

Schritt 2: Dedupe-Store persistent machen

Ein Dedupe-Store ist irgendein persistenter Speicher, der "gesehen" merken kann:

Datenbanktabelle mit Unique-Constraint auf idempotency_key
Key-Value-Store mit SETNX (set if not exists)
Ein internes "Data Store" Feature deines Automations-Tools

Wichtig ist: Der Store überlebt Deployments und Neustarts. Ein In-Memory-Cache ist für Tests nett, aber nicht für "ich will ruhig schlafen".

Praxis-Detail: Gib jedem Key eine TTL (z.B. 7-30 Tage), damit der Store nicht endlos wächst.

Schritt 3: Side-Effects absichern

Dedupe verhindert "zweimal denselben Workflow starten". Trotzdem kann es zwischenzeitlich zu Teilfehlern kommen (z.B. nach Schritt 3 bricht Schritt 4 ab, und ein Retry startet den Workflow neu).

Deshalb solltest du Side-Effects möglichst idempotent machen:

Upsert statt Create: "lege an, falls nicht vorhanden, sonst update"
Create mit externem Schlüssel: Viele Systeme erlauben eine externe ID, die du pro Event/Objekt deterministisch setzt
Vorher prüfen: Wenn es kein Upsert gibt, suche zuerst, ob das Objekt schon existiert, bevor du anlegst (kostet API-Calls, ist aber sicherer)

Faustregel: Alles, was "eine neue Sache erstellt" (Ticket, Kontakt, Datei, Mail), braucht einen Schutz gegen doppelte Erstellung.

Beispiel: Webhook "invoice.paid" ohne doppelte E-Mails

Du bekommst ein Event "Rechnung bezahlt". Du willst:

Task im Projekttool erstellen
E-Mail als Bestätigung schicken
Buchhaltungssystem aktualisieren

Robustes Design:

Idempotency Key: invoicePaid:{invoiceId}:{paymentId}
Dedupe-Store: speichert key + status + first_seen
Verarbeitung:
- wenn Key neu: verarbeiten
- wenn Key bekannt: abbrechen oder nur fehlende Side-Effects nachholen

In der Praxis sind die größten Fehlerquellen nicht die API-Calls selbst, sondern doppelte Side-Effects (zwei Mails, zwei Tasks). Genau da hilft Idempotenz.

Beispiel: Polling ohne Overlaps und Duplikate

Beim Polling holst du z.B. alle Rechnungen, die seit dem letzten Lauf geändert wurden.

Zwei robuste Varianten:

Checkpoint (Cursor) speichern: du merkst dir den letzten Cursor und pollst ab da weiter
Zeitfenster mit Overlap + Dedupe: du pollst z.B. "letzte 2 Stunden" und deduplizierst pro Objekt anhand invoiceId + updatedAt

Variante 2 ist oft einfacher, wenn APIs keine sauberen Cursor liefern, aber du brauchst dann zwingend Deduplizierung.

Checkliste: Ist deine Automation idempotent genug

Gibt es pro Trigger/Event eine stabile ID (oder baust du einen Key)?
Ist der Key pro Kunde/Workspace eindeutig gescoped?
Speichern duplizierte Runs den Key persistent, bevor Side-Effects passieren?
Sind "Create"-Schritte abgesichert (Upsert, externe ID, oder vorher prüfen)?
Gibt es eine TTL/Strategie, um alte Keys aufzuräumen?
Kannst du einen Run gefahrlos erneut starten, ohne dass etwas doppelt passiert?

Wenn du 4-6 Punkte mit "ja" beantworten kannst, bist du in der Praxis sehr gut aufgestellt.

Typische Fehler, die ich regelmäßig sehe

Random Keys pro Run Dann funktioniert Dedupe nicht, weil jeder Retry anders aussieht.
Dedupe nur im RAM Beim Deploy oder Neustart ist das Gedächtnis weg.
Keys ohne Tenant-Scope Dann kann ein Event von Kunde A ein Event von Kunde B blockieren.
Dedupe erst nach dem Side-Effect Dann sind doppelte Tickets und Mails schon passiert.
"Genau einmal" als Ziel In verteilten Systemen ist das selten realistisch. Baue lieber robust für at-least-once.

FAQ

Brauche ich Idempotenz wirklich, wenn mein Tool "zuverlässig" ist

Ja. Selbst wenn der Provider sauber ist, sind Timeouts, Deployments und Retries normal. Idempotenz ist eine Versicherung gegen genau diese Fälle.

Wie lange sollte ich Dedupe-Keys speichern

So lange, wie Duplikate realistisch auftreten können.

Als Startpunkt:

Webhooks: 7-14 Tage
Polling: 14-30 Tage (weil du oft größere Zeitfenster abdeckst)

Wenn du Monatsabschluss-Workflows hast, sind 30 Tage oft ein guter Default.

Wie mache ich das in No-Code Tools wie Make oder n8n

Die Idee bleibt gleich:

Nutze eine Event-ID oder baue einen Key.
Speichere Keys persistent (Data Store, Datenbank, KV-Store).
Sorge dafür, dass der Workflow bei "Key bereits gesehen" sauber stoppt.

Wenn du damit startest, ist ein Tool-Vergleich hier: Make vs. Alternativen

Transparenz

Dieser Blog kann Affiliate-Links enthalten. Aktuell liegt der Fokus auf Inhalten und Workflows. Wenn später Links ergänzt werden, werden sie klar gekennzeichnet.

Nächster Schritt

Webhooks und Polling robust einordnen: Webhook vs. Polling
Der Rahmen für stabile Automationen: Workflow-Automatisierung
Tool-Beispiel aus der Praxis: Make für IT-Freelancer
Zur Übersicht: Workflows: Automatisierung