Datenmodelle
Teil von Doppelte Aktionen verhindern
Einen eindeutigen Schlüssel für ein Ereignis wählen
Welche Ereigniskennung erkennt echte Wiederholungen? Prüfen Sie Stabilität, fachlichen Geltungsbereich, neue Vorgänge und widersprüchliche Parameter.
Bei jeder erneuten Zustellung desselben Ereignisses muss ein Ereignisschlüssel gleich bleiben; verschiedene Ereignisse muss er unterscheiden. Er sollte vom Absender stammen oder aus dessen stabilen Feldern gebildet werden, bevor eine wirksame Aktion startet. Eine erst beim Empfang erzeugte Lauf-ID erkennt Wiederholungen nicht.
Festlegen, was als gleich gelten soll
Soll nur dieselbe Nachricht erkannt werden, eignet sich häufig die Ereignis-ID des Absenders. Soll eine Folgeaktion auch dann nur einmal stattfinden, wenn unterschiedliche Ereignisse sie auslösen, reicht diese ID nicht aus.
Welche Merkmale eine passende fachliche Aktion unterscheiden, muss der Workflow zusätzlich prüfen.
Eine Regel kann beispielsweise „ein Erstellungsauftrag pro Freigabeversion“ lauten. Ihr Aktionsschlüssel könnte Vorgangskennung, Aktion und Freigabeversion enthalten. Ohne Version könnte eine spätere berechtigte Freigabe blockiert werden. Mit einer neuen Lauf-ID für jeden Versuch würde die Wiederholung unerkannt bleiben.
Schritte zur sicheren Auswahl eines Ereignisschlüssels
- Definieren Sie, was als gleich gilt (z. B. eine Freigabeversion)
- Wählen Sie stabile Felder aus dem Absender aus
- Prüfen Sie die Kriterien für Schlüsselqualität (Stabilität, Geltungsbereich, etc.)
- Speichern Sie den Schlüssel und zugehörige Parameter getrennt
- Implementieren Sie Überprüfungen auf widersprüchliche Anfragen
Einen Kandidaten prüfen
Prüfen Sie für jedes Schlüsselfeld:
- Bleibt es bei einer erneuten Zustellung oder einem Retry unverändert?
- Unterscheidet es neue berechtigte Vorgänge?
- Liegt es vor der Aktion vor?
- Ist sein Geltungsbereich klar, etwa Quelle, Mandant und Aktion?
- Bleibt die Zuordnung für die benötigte Wiederholungszeit erhalten?
Ein Empfangszeitpunkt ist als alleiniger Schlüssel ungeeignet. Auch ein Hash des gesamten Nachrichteninhalts ist nur dann sinnvoll, wenn genau dieser Inhalt die fachliche Gleichheit definiert: Unwichtige Feldänderungen können sonst Wiederholungen trennen, während identische Inhalte zwei gewollte Vorgänge zusammenführen können.
Gleicher Schlüssel, andere Absicht
Speichern Sie neben dem Schlüssel den Bearbeitungsstand und die wesentlichen fachlichen Parameter. Trifft derselbe Schlüssel mit widersprüchlichen Parametern ein, sollte der Fall sichtbar geprüft werden. Stripe meldet bei einer wiederholten API-Anfrage mit gleichem Idempotenzschlüssel und anderen Parametern einen Fehler. Das ist eine Stripe-Regel für API-Anfragen, keine allgemeine Webhook-Eigenschaft.
Dokumentieren Sie den Ereignisschlüssel und einen gegebenenfalls zusätzlichen Aktionsschlüssel getrennt. Dann lässt sich nachvollziehen, ob eine Nachricht erneut zugestellt wurde und ob ihre gewünschte Wirkung bereits eingetreten ist.
Vorteile und Risiken von Idempotenzschlüsseln
- Vorteil: Vermeidung doppelter Aktionen
- Erhöht die Zuverlässigkeit von Workflows
- Nachteil: Falsche Schlüsselwahl führt zu versteckten Wiederholungen
- Besonders bei dynamischen oder unspezifischen Feldern
- Vorteil: Klarer Audit-Trail durch separate Dokumentation von Schlüssel und Parametern
- Ermöglicht Nachvollziehbarkeit von Wiederholungen
- Nachteil: Widersprüchliche Parameter können zu Fehlermeldungen führen
- Stripe erkennt z. B. Idempotenzkonflikte und blockiert Anfragen
