Glossar · Automation & Workflows
Eigenschaft einer Operation, bei wiederholter Ausführung dasselbe Ergebnis zu liefern, kritisch für Retry-Sicherheit in verteilten Systemen.
Definition
In verteilten Systemen ist es nicht die Frage, ob ein Request doppelt ankommt, sondern wann. Webhooks werden bei Timeout nochmal gesendet, Queues haben At-Least-Once-Semantik, Netzwerke verlieren Antworten ohne den Request zu verlieren. Idempotente Endpoints liefern bei zwei identischen Requests dasselbe Ergebnis und keinen Double-Effect (kein doppelter Charge, kein doppelter Kontakt).
Umsetzung: Der Client schickt eine eindeutige Idempotency-Key (UUID), der Server speichert Key + Response für ein Zeitfenster (z. B. 24 h) und liefert beim zweiten Request die gleiche Antwort, ohne die Operation nochmal auszuführen.
HTTP-Konvention: GET und PUT sind per Definition idempotent, POST nicht. Wer POST idempotent machen will, braucht den Idempotency-Key, Stripe und viele moderne APIs liefern das nativ.
So nutzen wir das bei adsbird
Bei jedem Webhook-Receiver, den wir bauen, prüfen wir zuerst den Event-ID gegen eine Redis-Cache-Tabelle, ist der Event schon verarbeitet, antworten wir 200 und machen nichts. Klingt trivial, verhindert in der Praxis duplicate Stripe-Charges und doppelte CRM-Einträge.
Verwandte Begriffe
Wo wir Idempotenz im Detail erklären
Idempotenz in deinem Projekt?
Wenn du Idempotenz in einem konkreten Workflow brauchst, wir haben das wahrscheinlich schon gebaut.