Doppelte Webhook-Events sind kein Randproblem, sondern ein typischer Auslöser für doppelte Bestellungen, mehrfach ausgelöste E-Mails oder fehlerhafte Statuswechsel. Besonders häufig sehen wir das bei Magento- und WordPress-Integrationen, wenn Shops, CRM, Zahlungsanbieter oder AI-Services dieselbe Nachricht mehrfach senden oder ein Empfänger nicht idempotent arbeitet.
Die gute Nachricht: Man muss dieses Problem nicht mit Bauchgefühl lösen. Wer Ereignisse sauber misst, die Ursache entlang der Zustellkette eingrenzt und die Verarbeitung auf Wiederholungen vorbereitet, kann den Schaden meist schnell stoppen. Dieser Leitfaden zeigt eine praxistaugliche Schrittfolge für den Betrieb.
Woran man das Problem erkennt
Ein doppeltes Event sieht im Alltag oft anders aus als im Log. Typische Symptome sind:
- gleiche Bestellung wird zweimal im ERP angelegt
- eine Zahlungsbestätigung löst zwei E-Mails aus
- ein Lead erscheint doppelt im CRM, obwohl das Formular nur einmal abgeschickt wurde
- der Status wechselt kurz auf „bezahlt“ und springt später zurück
Ein Schweizer Detail aus der Praxis: Bei einem B2B-Portal mit hoher Formularlast tauchten dieselben Webhook-Payloads binnen 30 Sekunden mehrfach auf, weil der Sender bei einem Timeout automatisch erneut zustellte. Der Schaden war nicht der zweite Request selbst, sondern die fehlende Idempotenz auf Empfängerseite.
Wichtige Kennzahlen für die Erstdiagnose sind:
- Duplicate Rate: Anteil doppelter Events pro 1’000 Requests
- Retry Rate: wie oft der Sender dieselbe Nachricht erneut versucht
- Median Time to Acknowledge: wie schnell der Empfänger mit 2xx antwortet
- Processing Lag: Zeit zwischen Event-Eingang und fachlicher Verarbeitung
Schritt 1: Die Kette sichtbar machen
Bevor man etwas ändert, muss die Zustellkette lückenlos sichtbar werden. Für jedes Event braucht es mindestens diese Datenpunkte: Zeitstempel, Event-ID, Quellsystem, Zielsystem, HTTP-Status, Payload-Hash und eine eindeutige fachliche Referenz wie Bestellnummer oder Kunden-ID.
Praktisch bewährt hat sich diese Reihenfolge:
- Sender-Log prüfen: Wurde das Event einmal oder mehrfach erzeugt?
- Transport prüfen: Kam ein Timeout, ein 5xx oder ein Netzwerkabbruch vor?
- Empfänger-Log prüfen: Wurde dieselbe Event-ID mehrfach verarbeitet?
- Fachlogik prüfen: Ist die Verarbeitung nur technisch oder auch fachlich abgesichert?
Ein häufiger Fehler ist die Verwechslung von erneuter Zustellung mit echtem Doppelereignis. Viele Systeme senden bei Unsicherheit erneut, weil sie keine eindeutige Bestätigung erhalten haben. Das ist kein Bug im engeren Sinn, aber ohne Schutzmechanismus wird daraus sofort ein Betriebsproblem.
Schritt 2: Idempotenz statt Hoffnung
Der wichtigste technische Hebel ist Idempotenz. Der Empfänger muss ein Event so behandeln, dass dieselbe Nachricht beliebig oft ankommen darf, ohne den fachlichen Zustand zu verfälschen. Das geht je nach System auf drei Ebenen:
- Event-ID sperren: Jede bekannte ID wird nur einmal akzeptiert.
- Fachschlüssel sperren: Zum Beispiel Bestellung + Status + Datum als eindeutiger Schlüssel.
- Side Effects entkoppeln: E-Mail, ERP, Tracking und Queue getrennt verarbeiten.
Bei Magento-Integrationen ist das oft die sauberste Lösung, wenn Zahlungsanbieter oder Middleware erneut zustellen. In WordPress-Projekten betrifft es meist Formular-Plugins, CRM-Anbindungen oder Automationen mit mehreren Triggern. Der entscheidende Punkt ist immer derselbe: erst prüfen, dann schreiben.
Für die Abnahme lohnt sich ein klarer Vorher/Nachher-Vergleich:
- Vorher: 2 bis 5 doppelte Fachaktionen pro 1’000 Events, unklare Ursachenlage, manuelle Korrekturen
- Nachher: 0 doppelte Fachaktionen in einem Testfenster von 7 Tagen, nachvollziehbare Event-ID-Kette, definierter Retry-Weg
Schritt 3: Entscheidungsmatrix für die Entschärfung
Nicht jedes Problem braucht dieselbe Massnahme. Diese einfache Matrix hilft bei der Entscheidung:
- Hohe Retry-Rate, saubere Event-IDs: Idempotenz-Cache oder dedizierte Event-Tabelle einführen
- Keine stabile Event-ID: fachlichen Schlüssel definieren und Event normalisieren
- Mehrere Trigger auf dasselbe Ziel: Workflow vereinheitlichen und doppelte Pfade entfernen
- Unklare Timeouts: Response-Zeiten optimieren und Ack sofort zurückgeben, Verarbeitung asynchron auslagern
Für operative Teams ist das wichtig, weil man nicht blind an der Infrastruktur drehen sollte. Oft ist das Problem nicht „zu wenig Serverleistung“, sondern ein fehlendes Zustellprotokoll oder eine unklare Trennung zwischen Empfang und Verarbeitung.
Checkliste für die Abnahme
Vor dem Go-live sollte diese Liste erfüllt sein:
- jede Event-Kategorie hat eine dokumentierte eindeutige ID oder einen fachlichen Schlüssel
- der Empfänger speichert verarbeitete Events mit Status und Zeitstempel
- Retries werden erkannt und sauber protokolliert
- fachliche Nebenwirkungen sind von der HTTP-Antwort entkoppelt
- ein Testfall mit absichtlicher Doppelzustellung produziert kein doppeltes Geschäftsergebnis
- es gibt einen definierten Eigentümer für Sender, Empfänger und Middleware
Cytracon setzt in solchen Audits genau dort an: erst die Messkette klären, dann die Ursache eingrenzen, dann die kleinste robuste Korrektur umsetzen. Das spart Zeit und verhindert, dass man ein Symptom im falschen Layer bekämpft.
Wer doppelte Events einmal sauber in den Griff bekommt, gewinnt nicht nur Stabilität, sondern auch Vertrauen in die Integrationen. Und genau das ist im Tagesgeschäft meist wertvoller als eine weitere kosmetische Optimierung.
Wenn Sie Webhooks, Formular- oder Bestellflüsse systematisch entschärfen möchten, finden Sie uns unter cytracon.com/kontakt.
