Idempotenz
Idempotenz hält die fachliche Wirkung derselben logischen Operation bei Wiederholung stabil. Eine eindeutige Kennung verbindet alle Versuche mit dem gespeicherten Ergebnis.
- SchlüsselVerbindet alle Versuche einer Absicht.
- Gespeichertes ErgebnisWiederholung liefert dasselbe Ergebnis.
- Gleiche AbsichtAnderer Inhalt ist ein Konflikt.
Einordnung
Warum das wichtig ist
Wiederholungen sind bei verlorenen Antworten normal. Ohne Idempotenz kann derselbe Aufruf zweimal wirken, hier eine doppelte Belastung. Die Entscheidung, ob und wann wiederholt wird, behandelt Retry.
Dieser Baustein erklärt sichere Wiederholung derselben Operation. Für die Entscheidung über erneute Versuche siehe Retry.
Auf einen Blick · Wiederholung mit gleichem Schlüssel
Eine Belastung trotz Wiederholung
Das Zahlungsmodul sendet B-1042 mit dem Schlüssel pay-B-1042 an den externen Anbieter. Die erste Antwort geht verloren.
So liest du das Bild
- Schlüssel Mit „pay-B-1042“ erkennt der Anbieter die Wiederholung als denselben Auftrag.
- Gespeichertes Ergebnis Der Ergebnisspeicher meldet „Z-9 bereits vorhanden“, die Belastung bleibt bei 1 × 49,90 €.
- Gleiche Absicht Beide Versuche tragen denselben Schlüssel und dieselben 49,90 €, nur dann gilt es als Duplikat.
- läuftZahlungsmodulAntwort kam an, kein Retry
- läuftZahlungsanbieterbelastet einmal
- HinweisErgebnisspeicherwird nicht gebraucht
- läuftBelastung von B-10421 × 49,90 €
1Belastungen von B-1042
Kommt die Antwort an, gibt es keine Wiederholung. Der Schlüssel zeigt hier noch keinen Unterschied.
Nutzen & Grenzen
Hilft, wenn
- Ein stabiler Schlüssel ordnet erneute Aufrufe derselben Operation zu und klärt einen ungewissen Ausgang.
- Eine atomare Zuordnung aus Schlüssel, Anfrage und Änderung schützt die fachliche Wirkung vor paralleler oder wiederholter Ausführung.
- Externe Effekte erhalten eine eigene Wiedererkennung und Statusklärung jenseits der lokalen Datenbanktransaktion.
Grenzen
- Der Schlüssel muss dieselbe Absicht über alle Versuche stabil bezeichnen; ein neuer Schlüssel je Versuch hebelt den Schutz aus.
- Das gespeicherte Ergebnis braucht Aufbewahrung und Platz; nach Ablauf gilt eine Wiederholung wieder als neuer Auftrag.
- Idempotenz sichert Wiederholungen ab, entscheidet aber nicht, ob wiederholt wird; das regelt Retry.
In der Praxis
- Definiere die stabile Kennung pro logischer Operation und binde sie an den unveränderten Requestinhalt. Derselbe Schlüssel mit abweichendem Inhalt braucht eine eindeutige Konfliktantwort.
- Speichere Schlüssel, fachliche Änderung und zurückzugebendes Ergebnis innerhalb derselben atomaren Grenze. Damit liefert eine Wiederholung dasselbe bekannte Resultat statt eine zweite Wirkung auszulösen.
- Behandle externe Effekte mit eigener Wiedererkennung oder Statusabfrage. Retry steuert Versuche; Transactional Outbox sichert Nachrichtenversand.
Ausführliche Erklärung lesen
Eine Operation ist idempotent, wenn ihre wiederholte Ausführung mit derselben fachlichen Absicht denselben Zustand hinterlässt wie eine einmalige Ausführung. Das Ergebnis muss dabei nicht dieselben Antwortdaten enthalten; entscheidend ist die Wirkung auf den Zustand. Auch das Setzen eines Zielzustands kann daher idempotent sein.
Ein stabiler Schlüssel macht Wiederholungen als dieselbe logische Operation erkennbar. Schlüssel, Anfrage-Fingerabdruck, fachliche Änderung und abrufbares Ergebnis müssen atomar zusammengehören; ein Schlüssel mit abweichendem Anfrageinhalt erhält eine definierte Konfliktantwort. Bei gleichzeitig eintreffenden Wiederholungen sichern Eindeutigkeit und Transaktion die einzelne Änderung. Externe Wirkungen liegen außerhalb dieser lokalen Atomarität und brauchen eine eigene Zustell- und Empfängerstrategie.
Retry entscheidet, wann ein Versuch wiederholt wird; Idempotenz sorgt dafür, dass derselbe Schlüssel mit derselben Anfrage dieselbe Operation bezeichnet. Transactional Outbox behandelt spätere externe Zustellung.
Bei HTTP trägt oft ein Header Idempotency-Key den Schlüssel, im Shop etwa pay-B-1042.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie oft wird B-1042 belastet, wenn die Antwort verloren geht und der Schlüssel fehlt?
Lösung mit Begründung ansehen
Zweimal, je 49,90 €. Mit Schlüssel pay-B-1042 nur einmal, als Z-9.
AnwendenAuf eine neue Lage übertragen
Die Antwort auf den ersten Versuch ging verloren. Was sendet die Zahlung beim zweiten Versuch?
Lösung mit Begründung ansehen
Denselben Schlüssel pay-B-1042 mit denselben 49,90 €, damit der Anbieter das vorhandene Ergebnis erkennt.
BewertenEine Alternative abwägen
Soll die Zahlung für jeden Versuch einen neuen Schlüssel erzeugen? Wie wägst du ab?
Lösung mit Begründung ansehen
Neue Schlüssel wirken unabhängig, aber der Anbieter kann die Wiederholung nicht als dieselbe Absicht erkennen und könnte erneut belasten. Der feste Schlüssel schützt vor doppelter Wirkung.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- IETF · HTTP Semantics (RFC 9110) (öffnet in neuem Tab)Normiert HTTP-Methoden, sichere und idempotente Operationen sowie Statuscodes.
- AWS Builders’ Library · Idempotent APIs (öffnet in neuem Tab)Erklärt Idempotenzschlüssel und sichere Wiederholungen verteilter Aufrufe.
- Stripe · Idempotent Requests (öffnet in neuem Tab)Konkreter API-Vertrag zu Idempotenzschlüsseln und wiederholten Anfragen.