Automatisierung ohne Idempotenz legt Aufträge doppelt an

Jede automatisierte Strecke fällt irgendwann in einen Zustand, in dem sie nicht weiß, ob ihr letzter Schritt angekommen ist. Das Netz bricht nach dem Absenden der Anfrage weg, aber vor dem Empfang der Antwort. Der aufrufende Prozess hat dann genau zwei Möglichkeiten, und beide sind ohne weitere Vorkehrung falsch: aufgeben und einen Vorgang verlieren — oder erneut senden und ihn doppelt anlegen.

Im Normalbetrieb fällt das nicht auf. Die Strecke läuft, die Protokolle sind grün, der Auftrag steht im Zielsystem. Erst Wochen später findet jemand zwei identische Belege, zwei Kommissionierlisten oder zwei Rechnungen zum selben Kundenwunsch. Dann beginnt die Suche nach einem „Fehler in der Schnittstelle“. Der Fehler sitzt früher: Es wurde nicht entschieden, was bei einem unklaren Ergebnis passieren darf.

Das ist keine API-Frage, die man der Entwicklungsabteilung überlassen kann. Es ist die Frage, ob das Unternehmen lieber einen Vorgang verliert oder einen Vorgang verdoppelt — und wer die Kosten trägt, wenn die Automatisierung rät.

Warum das eine Geschäftsfrage ist

Ein doppelter Auftrag ist kein technisches Artefakt. Im Warenwirtschaftssystem entsteht ein zweiter Beleg. Lager und Versand behandeln ihn als eigenen Vorgang, die Buchhaltung stellt eine zweite Rechnung, der Kunde erhält eine zweite Bestätigung. Die Korrektur kostet die Zeit aller beteiligten Stellen — und den Vertrauensverlust, wenn ein Kunde merkt, dass dasselbe zweimal ausgeführt wurde.

Bei Zahlungen ist die Lage schärfer. Eine wiederholte Auslösung ist keine interne Buchungszeile, sondern ein zweiter Abbuchungsversuch. Bei Nachrichten — Auftragsbestätigung, Versandavis — ist der Schaden kleiner, aber sichtbar. Die Automatisierung hat in allen drei Fällen dasselbe getan: Sie hat einen unsicheren Schritt wiederholt, weil sie das Ergebnis des ersten Versuchs nicht kannte.

Ein Mensch, der unsicher ist, ob der letzte Klick angekommen ist, schaut nach, bevor er erneut klickt. Die Automatisierung hat diesen Blick nicht, solange niemand ihn entworfen hat. Sie kennt nur „senden“ und „nochmal senden“.

Deshalb gehört die Frage nach Wiederholung in die Prozessaufnahme. Wer fragt, was bei einem Timeout passiert, entscheidet über Lagerbewegung, Forderung und Kundenkommunikation. Wer sie auf die Schnittstellenliste schiebt, hat sie nicht beantwortet, sondern verschoben.

Eine Automatisierung, die im Fehlerfall raten muss, hat den Fehlerfall nicht entworfen, sondern ins Zielsystem verlagert.

Was HTTP unter Idempotenz versteht

Eine Operation ist idempotent, wenn ihre mehrfache Ausführung denselben beabsichtigten Zustand hinterlässt wie ihre einmalige Ausführung. HTTP definiert diese Eigenschaft für Methoden. RFC 9110, Abschnitt 9.2.2 formuliert: Eine Methode gilt als idempotent, wenn die beabsichtigte Wirkung mehrerer identischer Anfragen auf dem Server dieselbe ist wie die einer einzelnen solchen Anfrage.

Von den dort definierten Methoden sind PUT, DELETE und die sicheren Methoden — darunter GET, HEAD und OPTIONS — idempotent. POST ist es nicht, PATCH ebenfalls nicht. Die Eigenschaft bezieht sich auf das, was der Aufrufer verlangt hat. Dass der Server jeden Versuch protokolliert, ändert daran nichts: Das sind Nebeneffekte, nicht die beabsichtigte Wirkung.

Der praktische Grund steht im selben Abschnitt. Eine idempotente Anfrage darf der Client automatisch wiederholen, wenn die Verbindung abreißt, bevor eine Antwort gelesen werden konnte. Bei PUT gilt: Nochmal senden hat dieselbe beabsichtigte Wirkung, auch wenn der erste Versuch schon durchgegangen ist. Die Antwort kann sich unterscheiden. Der Zustand darf es nicht.

Für nicht-idempotente Methoden gilt das Gegenteil. RFC 9110 sagt: Ein Client sollte eine solche Anfrage nicht automatisch wiederholen — es sei denn, er hat ein Mittel zu wissen, dass die Semantik in diesem Fall trotzdem idempotent ist, oder ein Mittel festzustellen, dass die ursprüngliche Anfrage nie angewendet wurde. Ein Proxy darf nicht-idempotente Anfragen nicht automatisch wiederholen.

Genau hier liegt das Entwurfsproblem. Der Vorgang, den man wiederholen möchte — einen Auftrag anlegen, eine Zahlung auslösen, eine Nachricht verschicken — ist fast immer ein POST. Die Methode, die HTTP für das Anlegen vorsieht, ist dieselbe, deren automatische Wiederholung die Spezifikation nicht freigibt.

Manche Clients raten trotzdem. RFC 9110 beschreibt das als riskanteren Weg: ein POST erneut senden, weil die Verbindung geschlossen wurde, bevor irgendein Teil der Antwort eintraf. In einer Automatisierung ist dieses Raten kein Randfall. Es ist die Standardreaktion auf Timeout, wenn niemand etwas anderes festgelegt hat.

Warum gerade Automatisierungen hier scheitern

Eine Strecke hat nur die Hinweise, die der Entwurf vorsieht. Timeout, abgebrochene Verbindung, Neustart des ausführenden Dienstes, doppelte Auslösung durch zwei parallele Worker — das sind keine Ausnahmen, sondern Betriebszustände. Drei Muster erzeugen denselben Schaden:

Blinde Wiederholung. Die Strecke behandelt jeden fehlgeschlagenen Versuch als „nicht angekommen“ und sendet denselben POST erneut. Das ist die häufigste Voreinstellung in Workflow-Werkzeugen: drei Versuche, dann Fehler. Der erste Versuch kann längst durch gewesen sein.

Neustart ohne Gedächtnis. Der Dienst bricht mitten im Lauf ab und startet von vorn. Ohne Vorgangsspeicher ist jeder bereits geschriebene Datensatz unsichtbar. Der zweite Lauf legt ihn noch einmal an.

Parallele Auslöser. Derselbe Geschäftsvorgang erreicht die Strecke zweimal — über Webhook und nächtlichen Abgleich, über zwei Worker, über eine manuelle Nachbearbeitung neben der Automatik. Ohne gemeinsamen Schlüssel sind das zwei Neuanlagen, nicht eine Wiederholung.

Alle drei Muster funktionieren im Test, weil der Test den Fehlerfall nicht enthält. Sie fallen auf, wenn jemand im Zielsystem aufräumt.

Der Idempotenzschlüssel

Die verbreitete Lösung dreht die Verantwortung um. Der Aufrufer erzeugt vor dem ersten Versuch einen eindeutigen Schlüssel und schickt ihn bei jedem Wiederholungsversuch unverändert mit. Der Server merkt sich Schlüssel und Antwort. Trifft derselbe Schlüssel erneut ein, führt er die Operation nicht erneut aus, sondern gibt die gespeicherte Antwort zurück.

POST /v1/auftraege HTTP/1.1
Host: api.beispiel.test
Idempotency-Key: "3f1c9a7e-8b04-4c1f-9a2e-15d0c6b7e4aa"
Content-Type: application/json

{"referenz": "AB-1042", "positionen": 3, "waehrung": "EUR"}

Der Schlüssel muss vom Aufrufer kommen, nicht vom Server. Sonst hätte jeder Versuch einen neuen, und die Wiederholung wäre wieder eine Neuanlage. Ein zufälliger UUID pro Vorgang ist richtig. Ein UUID pro Anfrage ist nutzlos: Er unterscheidet den Wiederholungsversuch nicht vom neuen Auftrag.

Für dieses Muster gibt es einen Standardisierungsentwurf der IETF, The Idempotency-Key HTTP Header Field. Er ist kein verabschiedetes RFC. Er schreibt aber fest, was in der Praxis gebraucht wird: Kopfzeilenname, Eindeutigkeit, Fehlerverhalten. Der Entwurf verlangt, dass der Schlüssel eindeutig ist und nicht mit einem anderen Nutzinhalt wiederverwendet wird. Als Erzeugung empfiehlt er einen UUID oder einen vergleichbaren Zufallswert.

Drei Antworten aus dem Entwurf gehören in den Entwurf der Strecke:

1. Erster Versuch. Schlüssel und Nutzinhalt sind neu. Der Server verarbeitet die Anfrage und speichert das Ergebnis.
2. Wiederholung nach Abschluss. Derselbe Schlüssel, derselbe Nutzinhalt, der erste Versuch ist fertig. Der Server gibt das gespeicherte Ergebnis zurück — Erfolg oder Fehler —, ohne die Operation erneut auszuführen.
3. Gleichzeitige Wiederholung. Derselbe Schlüssel trifft ein, während der erste Versuch noch läuft. Der Entwurf sieht dafür 409 Conflict vor. Die Strecke darf das nicht als Freigabe zum nochmaligen Senden lesen. Sie muss warten oder den Vorgang in eine Warteschlange legen.

Zwei weitere Antworten sind Entwurfsfehler auf der Aufruferseite. Fehlt der Schlüssel bei einer Operation, die ihn verlangt, antwortet der Server mit 400. Wird derselbe Schlüssel mit anderem Nutzinhalt wiederverwendet, antwortet er mit 422. Beides heißt: Der Aufrufer hat den Schlüssel nicht als Vorgangsidentität behandelt.

Der Entwurf lässt den Server eine Gültigkeitsdauer festlegen und verlangt, dass er sie veröffentlicht. Ein abgelaufener Schlüssel ist kein Schlüssel mehr. Eine Strecke, die nach Ablauf denselben Wert erneut sendet, legt unter Umständen an, was sie für eine Wiederholung hielt. Die Aufbewahrungsdauer ist Teil der Vereinbarung zwischen den Systemen.

Solange der Entwurf nicht verabschiedet ist, gilt zusätzlich: Die Kopfzeile heißt nicht überall Idempotency-Key. Zahlungs- und Plattform-APIs verwenden denselben Gedanken unter anderen Namen, gelegentlich auch im Rumpf statt in der Kopfzeile. Wer annimmt, das Feld heiße überall gleich, hat die Gegenstelle nicht gelesen.

Wenn die Gegenstelle nicht mitspielt

Viele Systeme, die in der Praxis angebunden werden — ältere Warenwirtschaften, branchenspezifische Fachverfahren, Produkte ohne gepflegte Programmierschnittstelle — kennen keinen Idempotenzschlüssel. Dann bleiben drei Wege, in dieser Reihenfolge:

1. Fachlicher Schlüssel statt technischer. Existiert im Zielsystem ein Feld, das den Vorgang eindeutig macht — eine Belegnummer, eine Bestellreferenz —, dann prüft der Ablauf vor dem Schreiben, ob der Datensatz schon da ist, oder das Zielsystem lehnt das Duplikat ab. Das ist kein echtes Idempotenzverfahren im Sinne von RFC 9110: Zwischen Prüfung und Schreiben bleibt eine Lücke, in der zwei parallele Versuche beide „nicht vorhanden“ sehen und beide anlegen. Es fängt aber den häufigen Fall der seriellen Wiederholung ab, wenn das Zielsystem die Eindeutigkeit erzwingt.

2. Ein eigener Vorgangsspeicher. Die Automatisierung protokolliert selbst, welcher Geschäftsvorgang mit welchem Ergebnis abgeschlossen wurde, und fragt diesen Speicher vor jedem Versuch. Damit wandert die Verantwortung in die eigene Hand. Der Speicher muss denselben Vorgang über Neustarts hinweg wiedererkennen, er muss gesichert werden, und er muss eine Antwort auf die gleichzeitige Ausführung haben. Ohne diese drei Eigenschaften ist er ein Log, kein Schutz.

3. Keine automatische Wiederholung. Bei unklarem Ergebnis läuft der Vorgang in eine sichtbare Warteschlange mit einer zuständigen Person. Das ist die langsamste Variante und die einzige, die ohne Mitwirkung der Gegenstelle keine Doppelbuchung erzeugen kann. Sie bildet ab, was RFC 9110 von Clients verlangt, die nicht wissen, ob die ursprüngliche Anfrage angewendet wurde.

Die Reihenfolge ist Absicht. Wer bei Punkt drei anfängt, obwohl die Gegenstelle einen Schlüssel anbietet, verschenkt Verlässlichkeit. Wer bei Punkt eins stehen bleibt, obwohl zwei Worker denselben Vorgang anfassen können, hat die Lücke nur verlegt.

Was im Entwurf einer Strecke geklärt sein muss

Bevor die erste Strecke gebaut wird, reichen fünf Fragen. Sie gehören auf dieselbe Liste wie Auslöser, Endzustand und Ausnahme.

Was ist die Identität des Vorgangs? Nicht die Identität der Anfrage. Ein Timeout erzeugt eine neue Anfrage. Es darf keinen neuen Auftrag erzeugen. Die Identität muss aus dem Geschäftsvorgang kommen oder vor dem ersten Versuch feststehen.

Welche Schritte dürfen automatisch wiederholt werden? Lesen fast immer. Anlegen, Auslösen, Versenden nur dann, wenn die Gegenstelle Idempotenz zusichert oder ein eigener Speicher den Vorgang wiedererkennt. Alles andere geht in die Warteschlange.

Was passiert bei 409, bei Timeout, bei Antwort ohne Körper? Drei Zustände, drei nächste Schritte. Wer sie in „nochmal versuchen“ zusammenzieht, hat die Unterscheidung aus RFC 9110 und aus dem IETF-Entwurf wieder aufgehoben.

Wie lange gilt ein Schlüssel — und was passiert nach Ablauf? Die Antwort steht in der Dokumentation der Gegenstelle oder in der eigenen Speicherregel. Steht sie nirgendwo, existiert sie nicht.

Wer sieht den Fall, den die Automatik nicht entscheiden kann? Ohne benannte Person und ohne sichtbare Warteschlange wird der unklare Fall entweder verschluckt oder verdoppelt. Beides ist teurer als die Warteschlange.

Diese Fragen ändern den Schnitt der Strecke, selten das Werkzeug. Eine Plattform, die Wiederholungen anbietet, ohne den Schlüssel durchzureichen, automatisiert das Raten.

Wie diese Klärung im Vorgehen verankert ist — Aufnahme, Streichen vor dem Bau, eine Strecke vollständig mit Fehlerbehandlung — steht unter Prozessautomatisierung. Ob die vorhandenen Schnittstellen einen Idempotenzschlüssel, einen fachlichen Eindeutigkeitsschutz oder keines von beiden hergeben, klärt ein System-Audit.

Der Normalbetrieb einer Strecke ohne diese Klärung ist kein Beweis, dass sie trägt. Er ist nur der Beweis, dass das Netz bisher stillgehalten hat.

Quellen

• RFC 9110 — HTTP Semantics, Abschnitt 9.2.2 „Idempotent Methods”
• IETF-Entwurf: The Idempotency-Key HTTP Header Field