Angenommen, Ihr Shop übergibt eine Bestellung an die Versandsoftware. Dort wird der Auftrag angelegt. Die Antwort erreicht die Automatisierung jedoch nicht mehr; der Lauf endet mit einem Fehler. Das Team sieht nur diesen Fehler. Wer nun den Vorgang erneut startet, kann einen zweiten Auftrag erzeugen, obwohl er nur den vermeintlich fehlenden nachholen will.
Dieses Problem beschreibt Amazon in seiner Builders’ Library anhand einer Ressourcenanlage: Bleibt die Antwort aus, weiß der Aufrufer zunächst nicht, ob seine Anforderung ausgeführt wurde. Die Funktion „erneut starten“ verlangt deshalb eine Zusage über den gesamten Ablauf. Dass ein Werkzeug automatische Wiederholungen anbietet, sagt noch nichts über deren Folgen.
Welche Lieferung wird wiederholt?
Viele Verbindungen beginnen mit einem Webhook: Ein Dienst meldet einem anderen, dass etwas passiert ist. Stripe warnt in seiner Webhook-Dokumentation vor Mehrfachzustellungen. Empfänger sollen die Kennungen bereits verarbeiteter Ereignisse speichern. Gelegentlich entstehen auch verschiedene Ereignisse für denselben Sachverhalt; dafür nennt Stripe die Kombination aus Objektkennung und Ereignistyp.
Das hilft beim Erkennen einer wiederholten Meldung. Für unseren Versandfall bleibt eine zweite Frage: Welcher konkrete Versandauftrag gehört zu ihr? Die Bestellnummer allein kann zu grob sein, wenn eine Bestellung mehrere Teillieferungen oder einen Ersatzversand bekommen darf.
Eine mögliche fachliche Kennung wäre B-104:versand:1 für den ersten vorgesehenen Versand zur Bestellung B-104. Sie bleibt beim Wiederholen erhalten. Ein ausdrücklich beauftragter weiterer Versand erhält eine eigene Kennung. Diese Unterscheidung muss Ihr Fachbereich mitentscheiden: Die Software kann aus zwei gleichen Adressen und Warenkörben nicht ableiten, ob Sie eine Wiederholung oder eine weitere Lieferung wünschen.
Das Protokoll schließt die Lücke nicht
Auch eine Liste erledigter Vorgänge kann im Beispiel zu spät kommen. Die Versandsoftware hat den Auftrag angelegt; unmittelbar danach bricht die Verbindung ab. Im Protokoll der Automatisierung fehlt der Erfolgseintrag. Beim nächsten Lauf sieht es so aus, als sei noch nichts geschehen.
Die technische Eigenschaft, die hier hilft, heißt Idempotenz: Dieselbe Anforderung lässt sich wiederholen, ohne eine zusätzliche Wirkung auszulösen. Amazon beschreibt dafür eine vom Aufrufer mitgegebene Kennung. Beim empfangenden Dienst müssen deren Speicherung und die zugehörigen Änderungen gemeinsam abgesichert sein. Sonst kann der Auftrag ohne gespeicherte Kennung entstehen – oder die Kennung ohne Auftrag. Amazon: Absicherung von Kennung und Änderung
Für Ihre Auswahl bedeutet das: Die Zusage muss den Aufruf einschließen, der den Versandauftrag tatsächlich anlegt. Ein Schutz vor doppelten Eingangsmeldungen beantwortet diese Frage noch nicht. Kann die Zielsoftware dieselbe Vorgangskennung sicher erneut annehmen, lässt sich die verlorene Antwort überbrücken. Andernfalls braucht es einen Abgleich mit dem vorhandenen Auftrag. Eine bloße Suche nach der Bestellnummer genügt dabei nicht, wenn zwei laufende Versuche beide nichts finden und anschließend beide einen Auftrag anlegen können.
Der Schutz kann früher enden als Ihr Betrieb
Auch eine dokumentierte Idempotenz hat Bedingungen. Bei Stripes API v1 können Kennungen entfernt werden, sobald sie mindestens 24 Stunden alt sind. Nach einer Entfernung behandelt Stripe die erneut verwendete Kennung als neue Anfrage. Daraus folgt weder eine Löschung genau nach 24 Stunden noch ein zugesicherter Schutz darüber hinaus. Diese Regel gilt für die genannte API, nicht pauschal für Automatisierungen. Stripe: Idempotente Anfragen
Daraus ergibt sich eine Betriebsfrage: Darf die Vertretung einen alten Fehler nach einem Wochenende noch einmal starten? Wenn der Wiederholungsschutz inzwischen abgelaufen sein kann, braucht dieser Neustart einen anderen Weg. Der bereits angelegte Auftrag muss sich eindeutig zuordnen lassen; solange der Ausgang ungeklärt bleibt, darf der Ablauf keinen weiteren anlegen. Diese Klärungsarbeit gehört zum Betrieb der Verbindung und damit auch in den Vergleich zwischen Kauf und Eigenentwicklung.
Lassen Sie sich vor der Freigabe genau den Fall aus dem Einstieg zeigen: Auftrag am Ziel angelegt, Antwort unterbrochen, derselbe Vorgang erneut gestartet. Das ist ein vorgeschlagener Abnahmefall; für diesen Artikel wurde keine Verbindung getestet. Maßgeblich ist, welcher Auftrag danach in der Versandsoftware steht und wie der erneute Lauf ihn zuordnet. Kann der Anbieter das nicht eindeutig zeigen, gehört dieser Fehler zur Klärung ins Team. Die automatische Wiederholung bleibt für diesen Fall gesperrt.
Quellen
- Amazon Builders’ Library: Making retries safe with idempotent APIs Geprüft am 5. November 2026
- Stripe: Handle duplicate events Geprüft am 5. November 2026
- Stripe: Idempotent requests Geprüft am 5. November 2026
Mehr zur Auswahl und Einordnung von Quellen steht in unserer Arbeitsweise.
Eine Angabe fehlt oder stimmt nicht?
Hinweis an die Redaktion ↗