Idempotenz: Warum sie Integrationen stabil macht – und wie.
Idempotenz: Warum sie Integrationen stabil macht
Eine idempotente Operation kann beliebig oft wiederholt werden – mit immer dem gleichen Ergebnis.
Warum Idempotenz so wichtig ist
Netzwerke sind unzuverlässig. Requests können zeitoutbehaftet sein, bevor eine Antwort ankommt. Dann die Frage: War der Request erfolgreich? Soll ich ihn wiederholen?
Wenn der Server idempotent ist: Ja, einfach wiederholen. Der Zustand ist danach der gleiche, egal ob einmal oder zehnmal gesendet.
Wenn nicht: Ein Retry könnte eine Zahlung doppelt ausführen, eine Bestellung zweimal erstellen, eine E-Mail zweimal senden.
Idempotency Keys
Das Pattern: Der Client sendet einen eindeutigen Key mit der Anfrage (Idempotency-Key: uuid-v4). Der Server speichert, welche Keys bereits verarbeitet wurden – und gibt bei Wiederholung einfach das gespeicherte Ergebnis zurück, ohne die Operation nochmal auszuführen.
Stripe nutzt dieses Pattern seit Jahren. Es ist der Standard für payment-ähnliche Operationen.
Was idempotent sein sollte
PUT (Update): by definition idempotent – das gleiche Objekt mehrfach auf denselben Stand setzen ist harmlos. DELETE: idempotent – etwas, das schon gelöscht ist, nochmal zu löschen, sollte kein Fehler sein. POST (Create): nicht by definition idempotent – deshalb Idempotency Keys.
Idempotenz in Queue-basierten Systemen
Wenn Nachrichten aus einer Queue verarbeitet werden, ist "exactly-once delivery" in verteilten Systemen schwer garantierbar. Die Lösung: at-least-once delivery + idempotente Verarbeitung.
Checkliste Idempotenz
Kritische POST-Operationen mit Idempotency Key abgesichert
Idempotency Key Storage mit TTL implementiert
Duplicate-Detection für Queue-basierte Systeme
PUT/DELETE-Operationen auf Idempotenz geprüft
Verhalten bei Retry-Scenarios getestet
Idempotenz in eure Integration einbauen?
markom.digital implementiert Idempotenz-Mechanismen für kritische Schnittstellen.
