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
Idempotenz in deinem Projekt?
Wenn du Idempotenz in einem konkreten Workflow brauchst — wir haben das wahrscheinlich schon gebaut.