Doppelte Abrechnungsvorgänge sind ein strukturelles Merkmal verteilter Systeme und kein Ausnahmefall. Wiederholungslogik, Netzwerkinstabilität, Neustarts von Anwendungen und Garantien für die erneute Zustellung von Nachrichten aus der Warteschlange führen allesamt zu Situationen, in denen derselbe abrechnungsrelevante Vorgang mehr als einmal an Ihr Abrechnungssystem übermittelt wird. Wenn Ihre Abrechnungsplattform diese Duplikate nicht korrekt entfernt, entstehen überhöhte Abrechnungen, und die Kunden entdecken diese Fehler, bevor Sie es tun.
Das Ziel der Ereignisdeduplizierung in der Abrechnung besteht darin, jedes einzelne abrechnungsfähige Ereignis genau einmal zu erfassen. Nicht zweimal (Überberechnung), nicht nullmal (Umsatzverlust) und auch nicht einmal bei den meisten Ereignissen und gelegentlich zweimal bei anderen (systematische, aber sporadische Überberechnungen, die am schwersten zu erkennen sind). Genau einmal. Jedes Mal. Unabhängig vom Umfang.
Die meisten Unternehmen stellen auf die schlimmste Art und Weise fest, dass sie ein Problem mit der Dublettenbereinigung haben: Ein Kunde bemerkt, dass seine Rechnung deutlich höher ausfällt als erwartet, und legt Widerspruch ein. Die Überberechnungen haben sich in der Regel über Wochen oder Monate hinweg angesammelt, da eine Dublettenrate von 0,1 % nicht bei jedem einzelnen Dublettenfall zu einer Beschwerde führt. Eine Beschwerde geht erst ein, wenn sich der kumulative Effekt schließlich in einer Rechnung bemerkbar macht. Systematische doppelte Abrechnungen rückwirkend aufzuspüren und zu korrigieren, wenn die Rechnungen bereits ausgestellt sind, ist um ein Vielfaches schwieriger, als sie von vornherein zu verhindern. Das früheste Anzeichen findet sich fast immer in Ihren Rohprotokollen und nicht in Ihren Rechnungsberichten. Die meisten Teams schauen dort erst nach, wenn bereits eine Reklamation vorliegt.
Woher Duplikate kommen
Logik für Wiederholungsversuche
Die häufigste Ursache. Wenn ein Ereignisproduzent ein Nutzungsereignis an Ihr Abrechnungssystem übermittelt und innerhalb eines Zeitfensters keine Bestätigung erhält, führt er einen erneuten Versuch durch. Wenn die erste Anfrage tatsächlich erfolgreich war, die Antwort jedoch verzögert eintraf oder verloren ging, befinden sich nun zwei Kopien desselben Ereignisses in der Pipeline. Bei geringen Transaktionsvolumina ist dies nur ein gelegentliches Ärgernis. Bei 10 Millionen Ereignissen pro Tag entspricht eine Wiederholungsrate von 0,5 % täglich 50.000 potenziellen Duplikaten.
„Mindestens einmal“-Zustellgarantien
Die meisten Nachrichtenwarteschlangen und Streaming-Plattformen (Kafka, SQS, Pub/Sub) arbeiten standardmäßig nach der „At-Least-Once“-Zustellungssemantik. Sie garantieren, dass jede Nachricht zugestellt wird, nicht jedoch, dass sie genau einmal zugestellt wird. Dies ist eine bewusste Designentscheidung: Die „Exactly-Once“-Zustellung ist auf Infrastrukturebene deutlich komplexer und kostspieliger zu realisieren. In der Praxis bedeutet dies, dass Ihre Anwendung doppelte Nachrichten erhält und Sie dafür verantwortlich sind, diese korrekt zu verarbeiten.
Wenn Ihre Pipeline zur Erfassung von Ereignissen einem dieser Systeme nachgeschaltet ist, erhalten Sie Duplikate. Die Frage ist, ob Ihr Abrechnungssystem damit umgehen kann.
Neustart der Anwendung und Fehlerbehebung
Wenn ein Dienst, der Abrechnungsereignisse erzeugt, nach einem Ausfall neu gestartet wird, kann es vorkommen, dass er im Rahmen seines Wiederherstellungsprozesses kürzlich aufgetretene Ereignisse erneut übermittelt. Wenn er keine Aufzeichnung darüber führt, welche Ereignisse bereits erfolgreich übermittelt wurden, werden diese erneut übermittelt. Dies kommt besonders häufig in IoT- und Telemetrie-Pipelines vor, in denen die Geräte-Firmware eine einfache Wiederherstellungslogik implementiert, die darauf basiert, „bei der Wiederherstellung der Verbindung den gesamten Pufferinhalt zu senden“, ohne dabei auf Duplikate zu achten.
Fehler in der Integrationsschicht
Selbst entwickelte Integrationsschichten zwischen Ihrem Produkt und Ihrem Abrechnungssystem sind ein fruchtbarer Nährboden für die Erzeugung doppelter Ereignisse. Ein Fehler in einem Webhook-Handler, ein Cron-Job, der unter bestimmten Bedingungen zweimal ausgelöst wird, ein Synchronisationsproblem zwischen zwei Datenquellen, die jeweils dieselbe Nutzungsmetrik erfassen – all dies kann zu systematischen Doppelströmen führen, die so lange bestehen bleiben, bis jemand die Unregelmäßigkeiten in den Rechnungen bemerkt.
So funktioniert die Ereignisdeduplizierung in der Abrechnung: Das Idempotenz-Schlüsselmuster
Der Standardansatz für die Deduplizierung von Ereignissen in der Abrechnung ist das Idempotenzschlüssel-Muster. Jedes Nutzungsereignis trägt eine eindeutige Kennung (den Idempotenzschlüssel), die vom Ereignisverursacher generiert wird und bei wiederholten Versuchen unverändert bleibt. Der Idempotenzschlüssel für ein bestimmtes Ereignis ist immer derselbe, unabhängig davon, ob das Ereignis einmal, zweimal oder zehnmal übermittelt wird.
Das Abrechnungssystem führt ein Protokoll der verarbeiteten Idempotenzschlüssel. Wenn ein Ereignis eingeht, gleicht das System den Schlüssel mit diesem Protokoll ab. Ist der Schlüssel bereits bekannt, handelt es sich um ein Duplikat, und das Ereignis wird verworfen. Ist der Schlüssel neu, wird das Ereignis verarbeitet und der Schlüssel dem Protokoll hinzugefügt.
Dieser Ansatz funktioniert zuverlässig, solange drei Bedingungen erfüllt sind:
- Jedes Ereignis verfügt über einen festen, eindeutigen Idempotenzschlüssel. Das Abrechnungssystem kann diesen nicht generieren; ein bei der Entgegennahme erstellter Schlüssel ist jedes Mal ein neuer Schlüssel, was bedeutet, dass Wiederholungsversuche nicht erfasst werden. Der Produzent muss ihn vor der ersten Übermittlung generieren und bei Wiederholungsversuchen beibehalten.
- Der Schlüssel wird aus dem Inhalt des Ereignisses abgeleitet, nicht aus den Metadaten der Übermittlung. Alles, was das empfangende System generiert (ein Server-Zeitstempel, eine fortlaufende ID), unterscheidet sich zwischen der ursprünglichen Übermittlung und dem erneuten Versuch. Stützen Sie sich daher auf Attribute des Ereignisses selbst: Kunden-ID, den eigenen Zeitstempel des Ereignisses, Metriktyp, Menge.
- Das Idempotenzprotokoll ist beständig und langlebig. Ein Protokoll im Arbeitsspeicher bleibt nach einem Neustart nicht erhalten. Alles, was vor dem Neustart übermittelt wurde, wird beim nächsten Eintreffen zu einem potenziellen Duplikat. Das Protokoll muss auf einem beständigen Speichermedium liegen, und das Rückblickfenster sollte mindestens mehrere Tage umfassen – bei Pipelines, in denen Ereignisse mit erheblicher Verzögerung eintreffen können, sogar noch länger.
Das Problem der übermäßigen Deduplizierung
Es kommt seltener vor (ist aber ebenso schädlich), dass die Duplikatserkennung bei der Abrechnung in die andere Richtung – also zu aggressiv – ausfällt. Wenn Ihre Duplikatserkennungslogik Ereignisse verwirft, die eigentlich keine Duplikate sind (weil sie zwar einige Merkmale mit einem früheren Ereignis gemeinsam haben, aber tatsächlich unterschiedlich sind), lassen Sie echte Nutzungsdaten unberücksichtigt und stellen zu wenig in Rechnung.
Dies geschieht am häufigsten, wenn Teams eine heuristische Deduplizierung anstelle einer schlüsselbasierten Deduplizierung einsetzen. Beispiel: „Wenn wir innerhalb von fünf Minuten zwei Ereignisse mit derselben Kunden-ID, demselben Metriktyp und derselben Menge erhalten, wird das zweite als Duplikat behandelt.“ Das Problem: Bei einem Kunden, der innerhalb von fünf Minuten zweimal dieselbe Aktion ausführt (zwei API-Aufrufe gleicher Größe, zwei identische Daten-Uploads), wird das zweite Ereignis stillschweigend verworfen.
Die idempotente, schlüsselbasierte Deduplizierung verhindert dies vollständig. Der Schlüssel ist stabil und eindeutig. Wenn zwei verschiedene Ereignisse zufällig dieselbe Kunden-ID, denselben Metriktyp und dieselbe Menge aufweisen, aber unterschiedliche Schlüssel haben, handelt es sich um unterschiedliche Ereignisse, die beide verarbeitet werden. Der Schlüssel ist das einzige Entscheidungskriterium.
Überlegungen zur Skalierung
Der Ansatz mit dem Idempotenz-Protokoll ist konzeptionell einfach, führt jedoch bei großem Umfang zu echten technischen Einschränkungen. Bei 10 Millionen Ereignissen pro Tag sammelt sich im Protokoll ein Volumen von 300 Millionen Einträgen pro Monat an. Die Suchzeit für Schlüssel, die Speicherung des Protokolls und die Richtlinien zur Aufbewahrungsdauer werden zu nicht trivialen Entwurfsentscheidungen.
Für eine Abrechnungsplattform ist dies ein gelöstes Problem, allerdings wird es von verschiedenen Anbietern auf unterschiedliche Weise gelöst, mit unterschiedlichen Leistungsmerkmalen und unterschiedlichen Aufbewahrungsfristen. Fragen Sie konkret nach:
- Wie lange werden die Einträge im Idempotenzprotokoll aufbewahrt? Wenn ein Wiederholungsversuch 30 Tage nach dem ursprünglichen Ereignis eintrifft, wird er dann korrekt als Duplikat identifiziert?
- Wie lange dauert die Suche bei einer Schlüsselprüfung bei höchstem Veranstaltungsaufkommen? Verursacht die Deduplizierung zusätzliche Latenz in der Erfassungspipeline?
- Bleibt das Idempotenzprotokoll auch bei Systemneustarts und Infrastrukturausfällen erhalten?
Erkennen von doppelten Ereignissen, die Sie bereits generieren
Wenn Sie sich nicht sicher sind, ob Ihr System Duplikate erzeugt, finden Sie hier eine praktische Überprüfung:
Ziehen Sie eine Stichprobe von Abrechnungsereignissen aus einem einzelnen Tag. Prüfen Sie für jedes Ereignis, ob dieselbe Kunden-ID, derselbe Metriktyp, dieselbe Menge und derselbe ungefähre Zeitstempel mehr als einmal im Protokoll vorkommen. Eine nicht unerhebliche Duplikatsrate (selbst 0,1 %) ist ein Hinweis darauf, dass Ihre Ereignisproduzenten Wiederholungsversuche generieren, die nicht abgefangen werden.
Falls Ihr Abrechnungssystem keine Rohereignisprotokolle bereitstellt und Sie lediglich die aggregierten Abrechnungsmengen einsehen können, ist diese Überprüfung nicht möglich. Das ist an sich schon ein Warnsignal. Sie sollten in der Lage sein, den Rohereignisstrom einzusehen, auf dessen Grundlage eine Rechnung erstellt wurde.
Häufig gestellte Fragen
Was versteht man unter der Deduplizierung von Ereignissen in der Abrechnung?
Die Ereignisdeduplizierung ist der Prozess, bei dem bereits verarbeitete Nutzungsereignisse identifiziert und verworfen werden, damit doppelte Übermittlungen nicht zu einer Überberechnung führen. Da die meisten Ereignisübermittlungssysteme die „At-Least-Once“-Semantik verwenden (die die Zustellung garantiert, jedoch keine „Exactly-Once“-Zustellung), erhalten Abrechnungssysteme naturgemäß doppelte Ereignisse. Die Deduplizierung ist der Mechanismus, der die „At-Least-Once“-Zustellung in eine „Exactly-Once“-Abrechnung umwandelt.
Was führt zu doppelten Abrechnungsvorgängen?
Drei Hauptursachen: „At-Least-Once“-Zustellungsgarantien von Nachrichtenwarteschlangen wie Kafka oder SQS, die jede Nachricht möglicherweise mehr als einmal zustellen; Anwendungsneustarts und Fehlerbehebung, bei denen Dienste gepufferte Ereignisse bei der Wiederherstellung der Verbindung erneut ausführen, ohne zu prüfen, ob sie bereits zugestellt wurden; sowie Fehler in der Integrationsschicht bei benutzerdefinierten Konnektoren, insbesondere bei Webhook-Handlern oder geplanten Jobs, die unter bestimmten Bedingungen mehr als einmal ausgelöst werden können.
Was ist ein Idempotenzschlüssel in der Ereignisverarbeitung?
Ein Idempotenzschlüssel ist eine eindeutige, stabile Kennung, die jedem Nutzungsereignis vom Ereignisverursacher zugewiesen wird. Der Schlüssel muss vor dem ersten Übermittlungsversuch generiert werden und bleibt bei Wiederholungsversuchen unverändert. Das Abrechnungssystem führt ein Protokoll aller Schlüssel, die es bisher erhalten hat; wenn ein Ereignis eintrifft, wird der Schlüssel überprüft – wurde er bereits zuvor gesehen, wird das Ereignis verworfen. Der Schlüssel muss vom Erzeuger stammen, nicht vom empfangenden System: Ein bei Empfang generierter Schlüssel ist immer ein neuer Schlüssel, was bedeutet, dass Wiederholungsversuche niemals als Duplikate erkannt werden.
Was ist Überdeduplizierung und warum ist sie gefährlich?
Eine Überdeduplizierung liegt vor, wenn Ihre Deduplizierungslogik Ereignisse verwirft, die eigentlich keine Duplikate sind, weil sie zwar Merkmale mit einem früheren Ereignis gemeinsam haben, aber eine tatsächlich unterschiedliche Nutzung darstellen. Wenn Ihre Logik beispielsweise jedes zweite Ereignis mit derselben Kunden-ID, demselben Metriktyp und derselben Menge innerhalb von fünf Minuten verwirft, verwerfen Sie stillschweigend den zweiten identischen API-Aufruf eines Kunden. Eine Überdeduplizierung führt zu einer Unterabrechnung und löst keine Kundenbeschwerden aus, sodass sie unbegrenzt fortbestehen kann. Eine idempotente, schlüsselbasierte Deduplizierung vermeidet dies vollständig: Der Schlüssel ist der einzige Entscheidungsfaktor, nicht der Inhalt.
Wie können Sie überprüfen, ob Ihr Abrechnungssystem doppelte Abbuchungen erzeugt?
Entnehmen Sie eine Stichprobe von Abrechnungsereignissen aus einem repräsentativen Tag. Prüfen Sie für jedes Ereignis, ob dieselbe Kunden-ID, derselbe Metriktyp, dieselbe Menge und derselbe ungefähre Zeitstempel mehr als einmal im Protokoll vorkommen. Eine Duplikatsrate von über 0,1 % deutet darauf hin, dass Ereignisgeneratoren unbehandelte Wiederholungsversuche erzeugen. Wenn Ihr Abrechnungssystem den rohen Ereignisstrom nicht offenlegt – sondern nur aggregierte Mengen –, können Sie diese Überprüfung nicht durchführen. Diese Einschränkung ist an sich schon ein Hinweis: Ein Abrechnungssystem, das Ihnen sein rohes Ereignisprotokoll nicht anzeigen kann, macht es unmöglich, die Ursache etwaiger Abrechnungsabweichungen zu diagnostizieren.
Den vollständigen Leitfaden für Fachleute zum Thema Messung und Einstufung finden Sie unter billingplatform.com/metering-and-rating.
Siehe auch: Was verursacht Umsatzverluste – und wie lassen sie sich verhindern ? | Was ist Abrechnungsmediation? | So funktionieren Tarifberechnungs-Engines: Ein technischer Leitfaden | Formelnbasierte Preisgestaltung: Wenn die Abfrage von Tarifstufen nicht ausreicht | So bewerten Sie eine Mess- und Tarifberechnungsplattform
