Idempotenz: warum ein Ablauf zweimal laufen darf, ohne doppelt zu wirken

Idempotenz bedeutet, dass eine Operation beliebig oft ausgeführt werden kann und trotzdem nur einmal wirkt: Ein zweiter Aufruf mit denselben Daten legt nichts Neues an, verschickt nichts erneut und hinterlässt denselben Stand wie der erste. Für automatisierte Abläufe ist diese Eigenschaft die Voraussetzung dafür, dass ein abgebrochener oder doppelt gestarteter Lauf gefahrlos wiederholt werden kann.

Was bedeutet Idempotenz?

Der Begriff stammt aus der Mathematik: Eine Abbildung ist idempotent, wenn ihre zweite Anwendung am Ergebnis der ersten nichts mehr ändert. Den Betrag einer Zahl zu nehmen ist so ein Fall, eine Zahl zu verdoppeln nicht. In der Softwareentwicklung wird der Gedanke auf Operationen übertragen, die Daten schreiben oder nach außen wirken.

• Idempotent ist „setze den Status dieser Bestellung auf versendet“: Nach dem dritten Aufruf steht dort derselbe Status wie nach dem ersten.
• Nicht idempotent ist „lege eine Rechnung an“ oder „erhöhe den Lagerbestand um den Wareneingang“: Jeder weitere Aufruf erzeugt eine weitere Rechnung oder bucht dieselbe Lieferung noch einmal ein.

Entscheidend ist also nicht, ob ein Schritt liest oder schreibt, sondern ob seine Wirkung an einer eindeutigen Kennung hängt. Wo es diese Kennung gibt, lässt sich fast jede schreibende Operation wiederholbar gestalten. Abzugrenzen ist der Begriff von der Transaktion: Sie sorgt dafür, dass ein Schritt ganz oder gar nicht ausgeführt wird. Ob er beim nächsten Anlauf ein zweites Mal ausgeführt wird, beantwortet sie nicht.

Warum ein automatisierter Lauf Daten zweimal sieht

Stößt ein Mensch einen Vorgang von Hand an, fällt eine Doppelung meist sofort auf. Ein automatisierter Lauf arbeitet ohne Zuschauer, und im Alltag gibt es drei Situationen, in denen er dieselben Daten erneut verarbeitet:

• Wiederholung nach einer Störung. Der Lauf bricht nach der Hälfte ab, weil ein Zielsystem nicht antwortet. Beim nächsten Start ist oft unklar, welche Datensätze schon geschrieben wurden – besonders dann, wenn die Verbindung genau nach dem Schreiben und vor der Bestätigung abriss.
• Überlappendes Abruffenster. Wer nur abholt, was seit dem letzten Lauf hinzugekommen ist, verliert Belege, die verspätet eingestellt werden oder in einer ausgefallenen Nacht angefallen sind. Belastbare Abläufe fragen deshalb bewusst einen längeren Zeitraum ab und sehen dabei die meisten Datensätze nicht zum ersten Mal.
• Doppelte Zustellung eines Webhooks. Viele Anbieter senden ein Ereignis erneut, wenn die Empfangsbestätigung nicht rechtzeitig eintrifft. Sie sichern damit zu, dass es mindestens einmal ankommt, nicht aber genau einmal.

Keine dieser Situationen ist ein Fehler, den man abstellen könnte; sie gehören zum Betrieb. Ohne Idempotenz wird aus jeder von ihnen eine Doppelbuchung, mit ihr ein gewöhnlicher Lauf.

Vier Verfahren, mit denen ein Ablauf idempotent wird

Die Verfahren ergänzen sich. Welches trägt, hängt davon ab, was Quelle und Zielsystem anbieten.

1. Natürlicher Schlüssel. Jeder Datensatz wird über eine Kennung erkannt, die aus der Quelle stammt und sich nicht ändert: die Rechnungsnummer des Ausstellers, die Bestellnummer des Shops, die Belegkennung im Fremdsystem. Eine intern hochgezählte Nummer taugt dafür nicht, weil beim zweiten Einfügen schlicht eine neue vergeben wird.
2. Upsert. Beim Schreiben wird über diesen Schlüssel entschieden, ob ein Datensatz neu angelegt oder der vorhandene aktualisiert wird. Datenbanken haben dafür eigene Befehle, in PostgreSQL etwa INSERT … ON CONFLICT. Eine Eindeutigkeitsregel auf dem Schlüssel verhindert, dass zwei gleichzeitige Läufe trotzdem eine Dublette erzeugen.
3. Idempotency-Key. Bei Aufrufen fremder Schnittstellen, die etwas auslösen – eine Zahlung, einen Versandauftrag –, schickt der Aufrufer eine eigene Kennung mit. Erkennt der Anbieter sie wieder, gibt er die Antwort des ersten Aufrufs zurück, statt den Auftrag noch einmal auszuführen. Das hilft nur, wenn die Kennung aus dem Vorgang abgeleitet und nicht bei jedem Versuch neu erzeugt wird.
4. Journal verarbeiteter Datensätze. Kennt das Ziel weder Schlüssel noch Idempotency-Key, etwa beim Versand einer E-Mail, führt der Ablauf selbst Buch über Kennung und Zeitpunkt jedes erledigten Vorgangs: vor dem Senden nachsehen, nach dem Senden eintragen. Dieses Journal ist zugleich ein Baustein des Audit-Trails.

Beim Journal bleibt eine schmale Lücke: Bricht der Lauf zwischen Senden und Eintragen ab, geht die Mail beim nächsten Versuch ein zweites Mal hinaus. Ganz schließen lässt sie sich nur auf der Seite des Empfängers. Wichtig ist, sie zu kennen und festzulegen, was weniger schadet – eine Nachricht doppelt oder keine.

Typische Fehler: doppelte Rechnungen und doppelte Mails

• Erst prüfen, dann schreiben – in zwei getrennten Schritten. Der Ablauf fragt, ob die Rechnung schon existiert, und legt sie im nächsten Schritt an. Laufen zwei Instanzen gleichzeitig, antworten beide mit Nein, und am Ende stehen zwei Rechnungen im System. Die Prüfung gehört als Eindeutigkeitsregel in die Datenbank.
• Schlüssel aus veränderlichen Feldern. Wer Datensätze an Name und Betrag wiedererkennt, bekommt eine Dublette, sobald in der Quelle ein Tippfehler korrigiert wird.
• Nebenwirkung vor dem Speichern. Die Bestätigungsmail geht hinaus, bevor der Auftrag gespeichert ist. Scheitert das Speichern, wiederholt der Ablauf alles, und der Kunde erhält dieselbe Bestätigung mehrmals.
• Wiederholversuche ohne wiederholbaren Schritt. Der Ablauf versucht fehlgeschlagene Schritte erneut, obwohl diese Schritte bei jedem Versuch neu anlegen. Die Ausnahmebehandlung wirkt dann sauber, während im Zielsystem Doppelbuchungen entstehen.
• Aufräumen statt verhindern. Ein regelmäßiges Skript löscht doppelte Zeilen im Nachhinein. Rechnungen und Mails, die schon beim Empfänger sind, holt es nicht zurück.

Idempotenz bei der Abnahme prüfen

Ob ein Ablauf Wiederholungen verträgt, lässt sich prüfen, ohne den Quelltext zu lesen. Für die Abnahme eignen sich vier Proben, die vorher als Kriterien festgehalten werden:

1. Zweiter Lauf über dieselben Daten. Den Lauf unmittelbar erneut starten. Erwartet: gleiche Anzahl Datensätze im Zielsystem, keine neuen Mails, keine neuen Belege.
2. Abbruch mitten im Lauf. Den Lauf nach einem Teil der Datensätze hart beenden und neu starten. Erwartet: am Ende jeder Datensatz genau einmal.
3. Dasselbe Ereignis doppelt. Einen Webhook zweimal mit identischem Inhalt einspielen. Erwartet: eine Wirkung, im Protokoll zwei Eingänge.
4. Korrektur in der Quelle. Einen bereits übernommenen Datensatz in der Quelle ändern und den Lauf wiederholen. Erwartet: eine aktualisierte Zeile, keine zweite.

Gemessen wird am Zielsystem und am Protokoll des Ablaufs, nicht an der Meldung, es sei alles durchgelaufen.

Wie wir Wiederholungen von Anfang an einplanen

Wir gehen bei jedem Ablauf davon aus, dass er Daten mehrfach sieht, und legen den Schlüssel jedes Datensatzes fest, bevor die erste Zeile geschrieben wird. Beim Abruf von Rechnungen aus dem staatlichen E-Rechnungssystem für einen Hersteller ist die Wiederholung sogar gewollt: Der nächtliche Lauf fragt jedes Mal ein Fenster von 14 Tagen ab, damit eine ausgefallene Nacht nichts verliert. Die meisten Rechnungen darin sind bereits bekannt; die Nummer, die das staatliche System jeder Rechnung vergibt, macht sie eindeutig, und ein erneuter Abruf aktualisiert die vorhandene Zeile. Bis September 2026 hat dieser Lauf 3 048 Rechnungen übernommen. Die vier Proben oben nehmen wir als Abnahmekriterien ins Angebot auf. Wie solche Abläufe entstehen, beschreibt die Seite Geschäftsprozesse automatisieren.