Ein Aufzug mit Anrufknopf funktioniert so: Zweimal auf den Aufzugknopf drücken heißt nicht zweimal fahren. Auch Automatisierungen bekommen solche zweiten Drücker.

Ein Webhook funktioniert wie ein Anruf, den der Absender wiederholt, bis jemand bestätigt: „Bin dran.“ Bleibt die Bestätigung aus, ruft er erneut an – auch wenn der Empfänger längst geöffnet hat. Genau dieser zweite Anrufversuch ist gewollt, damit kein Ereignis verloren geht. Der Empfänger erkennt an der eindeutigen Kennung, ob er diesen Anruf schon hatte.

Technisch arbeitet der Empfänger mit einer Ereignis-ID, also einer eindeutigen Kennung in jeder Nachricht. Der wiederholte Anruf ist die Zustellung eines Webhooks „at-least-once“ – der Sender liefert mindestens einmal. Und der Kassenbon ist die gespeicherte Ereignis-ID: Beim Eintreffen wird sie im Bestand gesucht; existiert sie schon, endet der Lauf sofort, sonst werden die Daten verarbeitet und die ID gespeichert.

Konkret: Ein Zahlungsdienst sendet einen Webhook für eine Buchung, der Empfänger verarbeitet ihn, doch die Antwort geht verloren. Sekunden später trifft derselbe Webhook mit derselben Ereignis-ID erneut ein. Ohne Prüfung entstünden zwei Buchungen; mit Webhook-Trigger gehört die Duplikatprüfung deshalb an den Anfang, vor jeden Schritt, der Daten anlegt oder versendet.

Das Bild hat eine Grenze: Ein Aufzug reagiert auf jeden Druck sofort gleich. Ein idempotenter Workflow überspringt das Duplikat, bestätigt dem Sender aber trotzdem den Empfang. Idempotenz heißt nicht „nichts tun“, sondern „nicht zweimal wirken“.

Wichtig ist die Reihenfolge: erst ID prüfen, dann verarbeiten. Signaturprüfung und Idempotenz lösen unterschiedliche Probleme: Die Signatur klärt, ob eine Nachricht echt ist; die Ereignis-ID, ob sie schon bearbeitet wurde.

📌 Idempotenz · Ereignis-ID · Duplikatprüfung

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #Webhooks #workflow