Finanzen sind einer der deutlichsten Bereiche, in denen das API-Design davon ausgehen muss, dass das Netzwerk unzuverlässig ist. Benutzer wiederholen Anfragen. Mobile Clients stellen die Verbindung erneut her. Gateways laufen ab. Hintergrundarbeiter wiederholen Nachrichten.
Wenn der Server eine logisch identische Anfrage nicht erkennen und das gleiche Ergebnis sicher zurückgeben kann, ist das System nicht defensiv genug für Geldbewegungen.
Wie ein idempotenter Vertrag aussieht
Eine typische API-Anfrage enthält einen Idempotenzschlüssel:
POST /payments
Idempotency-Key: 8b7b1b1c-8c3d-4ff0-a87a-5a148f7d4d4e
Der Server speichert den Schlüssel zusammen mit dem Ergebnis des ersten erfolgreichen Bearbeitungsversuchs. Wenn dieselbe Anfrage erneut eintrifft, wird das ursprüngliche Ergebnis zurückgegeben, anstatt eine zweite Zahlung zu erstellen.
Das ist der wichtige architektonische Punkt: Idempotenz ist kein Trick zur Wiederholung. Es ist ein serverseitiger Vertrag.
In der Praxis bedeutet das normalerweise, den Schlüssel mit einer Einzigartigkeitsgarantie zu persistieren und ihn mit der normalisierten Anfragestruktur sowie dem vorherigen Antwortpayload oder Ergebnisdatensatz zu verknüpfen.
Warum das wichtiger ist als Wiederholungslogik
Wiederholungen sind in verteilten Systemen normal. Doppelte Geldbewegungen sind es nicht.
Ohne Idempotenz können Wiederholungen Folgendes erzeugen:
- doppelte Belastungen
- doppelte Buchungseinträge
- inkonsistente downstream-Abstimmungen
Deshalb gehört Idempotenz in den Schreibpfad, bevor jemand feierlich über ausgeklügelte Wiederholungsmiddleware spricht.
Bessere Regel
Wenn die Operation Geld bewegen oder einen dauerhaften Nebeneffekt erzeugen kann, entwerfen Sie den Endpunkt so, dass er doppelte Absichten erkennt. In der Finanzwelt ist Idempotenz Teil der Korrektheit, nicht nur der Resilienz.
Weiterführende Literatur