Deduplizierung von Ereignissen

1) Warum Deduplizierung erforderlich ist

• Invarianten werden verletzt (doppelte Abschreibungen, wiederholte E-Mails/SMS, „doppelt erstellte“ Bestellung);
• steigende Kosten (wiederholte Aufzeichnungen/Verarbeitung);
• Die Analyse wird verzerrt.

Der Zweck der Deduplizierung besteht darin, einen einzigen beobachteten Effekt mit zulässigen Transportwiederholungen zu erzielen, oft zusammen mit Idempotenz.

2) Ort der Deduplizierung (Ebenen)

1. Edge/API-Gateway - Schneiden Sie explizite Takes durch 'Idempotency-Keu '/body + Signatur.
2. Broker/Stream - logische Deduplizierung nach Schlüssel/Sequenz, Coalescing bei einem Fehler (seltener - wegen der Kosten).
3. Ereignisempfänger (Consumer) - Hauptort: Posteingang/Schlüsseltabelle/Cache.
4. Synk (DB/Cache) - eindeutige Schlüssel/UPSERT/Versionen/Kompression.
5. ETL/Analyse - Dedup nach Zeitfenster und Schlüssel in Säulensektoren.

Regel: so früh wie möglich, aber unter Berücksichtigung der Kosten für falsch positive Ergebnisse und der Notwendigkeit von Replikationen.

3) Deduplizierungsschlüssel

3. 1 Natürlich (bevorzugt)

`payment_id`, `order_id`, `saga_id#step`, `aggregate_id#seq`.
Sie garantieren Stabilität und Sinn.

3. 2 Zusammengesetzte

`(tenant_id, type, external_id, version)` или `(user_id, event_ts_truncated, payload_hash)`.

3. 3 Impressum (Fingerabdruck)

Hash einer deterministischen Teilmenge von Feldern (Reihenfolge/Register normalisieren), optional 'HMAC (secret, payload)'.

3. 4 Sequenzen/Versionen

Monotone' seq 'per aggregate (optimistische Blockierung/Versionierung).

Anti-Muster: „randomisierte UUID“ ohne Verbindung zur Geschäftseinheit - Dedup ist nicht möglich.

4) Zeitfenster und Reihenfolge

Deduplizierungsfenster - der Zeitraum, in dem ein Ereignis erneut auftreten kann (in der Regel 24-72 Stunden; für die Finanzen länger).
Out-of-order: Wir erlauben Verspätung (Latenz). In den Streaming-Frameworks gibt es Eventzeit + Wasserzeichen.
Sliding/Fix-window dedup: "Haben Sie den Schlüssel in den letzten N Minuten gesehen? ».
Sequence-aware: wenn 'seq' ≤ der zuletzt bearbeiteten - take/repeat.

5) Datenstrukturen und Implementierungen

5. 1 Genaue Buchführung (exact)

Redis SET/STRING + TTL: 'SETNX key 1 EX 86400' → „zum ersten Mal - verarbeiten, sonst - SKIP“.
LRU/LFU-Cache (in-proc): schnell, aber volatil → besser nur als erste Barriere.
SQL eindeutige Indizes + UPSERT: „einfügen oder aktualisieren“ (idempotenter Effekt).

5. 2 Näherungsstrukturen (probabilistisch)

Bloom/Cuckoo-Filter: billiger Speicher, False Positive möglich. Geeignet für explizite „laute“ Drops (z.B. Telemetrie), nicht für Finanzen/Aufträge.
Count-Min Sketch: Schätzung der Frequenzen zum Schutz vor „heißen“ Takes.

5. 3 Streaming-Zustände

Kafka Streams/Flink: keyed state store c TTL, dedup durch den Schlüssel im Fenster; checkpoint/restore.
Wasserzeichen + zulässige Latenz: Steuert das Fenster für verspätete Veranstaltungen.

6) Transaktionsmuster

6. 1 Posteingang (eingehende Tabelle)

pseudo
BEGIN;
ins = INSERT INTO inbox(id, received_at) ON CONFLICT DO NOTHING;
IF ins_not_inserted THEN RETURN cached_result;
result = handle(event);
UPSERT sink with result; -- idempotent sync
UPDATE inbox SET status='done', result_hash=... WHERE id=...;
COMMIT;

Die Wiederholung wird die Aufnahme sehen und den Effekt nicht wiederholen.

6. 2 Outbox

Geschäftsaufzeichnung und Ereignis in einer Transaktion → der Publisher gibt dem Broker. Beseitigt nicht die Aufnahme vom Verbraucher, aber schließt „Löcher“ aus.

6. 3 Einzigartige Indizes/UPSERT

sql
INSERT INTO payments(id, status, amount)
VALUES ($1, $2, $3)
ON CONFLICT (id) DO NOTHING; -- "create once"

sql
UPDATE orders
SET status = $new, version = version + 1
WHERE id=$id AND version = $expected; -- optimistic blocking

6. 4 Versionierung von Aggregaten

Das Ereignis ist anwendbar, wenn 'event. version = aggregate. version + 1`. Ansonsten - Doppel/Wiederholung/Konflikt.

7) Dedup und Broker/Streams

7. 1 Kafka

Idempotent Producer reduziert die Takes am Eingang.
Mit Transactions können Sie Offset- und Output-Einträge atomar ausführen.
Compaction: speichert den letzten Wert per key - Post-Fact-Dedup/Coalesing (nicht für Zahlungen).
Verbraucherseite: State Store/Redis/DB für Fensterschlüssel.

7. 2 NATS / JetStream

Ack → at-least-once. Dedup im Verbraucher (Inbox/Redis).
JetStream-Sequenz/Durabot-Verbraucher erleichtern die Identifizierung von Wiederholungen.

7. 3 Warteschlangen (Rabbit/SQS)

Visibility timeout + re-Lieferung → benötigen Schlüssel + dedup-stor.
SQS FIFO mit 'MessageGroupId '/' DeduplicationId' hilft, aber die TTL des Fensters ist auf den Anbieter beschränkt - speichern Sie die Schlüssel länger, wenn das Geschäft es erfordert.

8) Speicher und Analysen

8. 1 ClickHouse/BigQuery

Dedup am Fenster: 'ORDER BY key, ts' und 'argMax '/' anyLast' mit Bedingung.

sql
SELECT key,
anyLast(value) AS v
FROM t
WHERE ts >= now() - INTERVAL 1 DAY
GROUP BY key;

Oder eine materialisierte Schicht von „einzigartigen“ Ereignissen (Merge nach Schlüssel/Version).

8. 2 Protokolle/Telemetrie

Nehmen wir approximate-dedup (Bloom) auf ingest an → wir sparen Netzwerk/Laufwerk.

9) Re-Processing, Replikate und Backfill

Dedup-Schlüssel müssen Replikate (TTL ≥ Replikatfenster) überleben.
Verwenden Sie für Backfill den Schlüsselraum mit der Version ('key # source = batch2025') oder einzelne „Pflaumen“, um das Online-Fenster nicht zu stören.
Speichern Sie Ergebnisartefakte (Hash/Version) - dies beschleunigt das „Fast-Skip“ bei Wiederholungen.

10) Metriken und Beobachtbarkeit

„dedup _ hit _ total “/„ dedup _ hit _ rate“ ist der Anteil der gefangenen Takes.
'dedup _ fp _ rate' für probabilistische Filter.
'window _ size _ seconds' ist real (nach telemetry late arrivals).
`inbox_conflict_total`, `upsert_conflict_total`.
`replayed_events_total`, `skipped_by_inbox_total`.
Profile von tenant/key/type: wo die meisten Takes sind und warum.

Логи: `message_id`, `idempotency_key`, `seq`, `window_id`, `action=process|skip`.

11) Sicherheit und Privatsphäre

Setzen Sie die PII nicht in den Schlüssel; Verwenden Sie Hashes/Aliase.
Für die Signatur des Fingerabdrucks - HMAC (secret, canonical_payload), um Kollisionen/Fälschungen zu vermeiden.
Die Aufbewahrungsfristen der Schlüssel stimmen mit der Compliance (DSGVO-Retention) überein.

12) Leistung und Kosten

In-proc LRU ≪ Redis ≪ SQL nach Latenz/Kosten pro Operation.
Redis: billig und schnell, aber berücksichtigen Sie das Volumen der Schlüssel und TTL; shardate durch 'tenant/hash'.
SQL: teuer auf p99, bietet aber starke Garantien und Audits.
Probabilistische Filter: sehr günstig, aber FP möglich - dort anwenden, wo „extra SKIP“ nicht kritisch ist.

13) Anti-Muster

„Wir haben Kafka exactly-once - den Schlüssel braucht man nicht“. Gebraucht - in blau/Business-Schicht.
Zu kurze TTL für Schlüssel → Replikate/Verzögerung liefert die doppelte.
Globaler einzelner Dedup-Stor → Hotspot und SPOF; nicht nach Tenant/Schlüssel aufgeschrieben.
Dedup nur im Gedächtnis - Prozessverlust = Welle von Takes.
Bloom für Geld/Bestellungen - false positive wird den legitimen Betrieb berauben.
Unkoordinierte payload Kanonisierung - verschiedene Hashes auf identische Nachrichten im Sinne.
Ignorieren Sie Out-of-Order - späte Ereignisse werden fälschlicherweise mit Doppeln markiert.

14) Checkliste Umsetzung

• Identifizieren Sie den natürlichen Schlüssel (oder Composite/Print).
• Legen Sie das Dedup-Fenster und die Richtlinie „lateness“ fest.
• Wählen Sie die Ebene (n): edge, consumer, sink; Sorgen Sie für Sharding.
• Implementieren Sie Inbox/UPSERT; für Threads - Schlüsselzustand + TTL.
• Wenn Sie eine approximale Barriere benötigen - Bloom/Cuckoo (nur für unkritische Domains).
• Konfigurieren Sie die Replay-Kompatibilität (TTL ≥ Replay/Backfill-Fenster).
• 'dedup _ hit _ rate' Metriken, Konflikte und Fensterverzögerungen; Dashboards per tenant.
• Game Day: Timeouts/Retrays, Replays, Out-of-Order, Cache Drop.
• Dokumentieren Sie die Kanonisierung von payload und die Versionierung von Schlüsseln.
• Führen Sie Belastungstests an „Hot Keys“ und langen Fenstern durch.

15) Beispiele für Konfigurationen/Code

15. 1 Redis SETNX + TTL (Barriere)

lua
-- KEYS[1] = "dedup:{tenant}:{key}"
-- ARGV[1] = ttl_seconds local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "PROCESS"
else return "SKIP"
end

15. 2 PostgreSQL Inbox

sql
CREATE TABLE inbox (
id text PRIMARY KEY,
received_at timestamptz default now(),
status text default 'received',
result_hash text
);
-- In the handler: INSERT... ON CONFLICT DO NOTHING -> check, then UPSERT in blue.

15. 3 Kafka Streams (Dedup im Fenster)

java var deduped = input
.selectKey((k,v) -> v.idempotencyKey())
.groupByKey()
.windowedBy(TimeWindows. ofSizeWithNoGrace(Duration. ofHours(24)))
.reduce((oldV,newV) -> oldV)   // first wins
.toStream()
.map((wKey,val) -> KeyValue. pair(wKey. key(), val));

15. 4 Flink (Schlüsselzustand + TTL, Pseudo)

java
ValueState<Boolean> seen;
env. enableCheckpointing(10000);
onEvent(e):
if (!seen.value()) { process(e); seen. update(true); }

15. 5 NGINX/API-Gateway (Idempotency-Key am Rand)

nginx map $http_idempotency_key $idkey { default ""; }
Proxy the key to the backend; backend solves deadup (Inbox/Redis).

16) FAQ

F: Was soll ich wählen: Dedup oder reine Idempotenz?
A: Normalerweise beides: Dedup ist ein schneller „Filter“ (Sparen), Idempotenz ist eine Garantie für den richtigen Effekt.

F: Welche TTL setzen?
A: ≥ der maximalen Zeit der möglichen Nachlieferung + Lager. Typisch 24-72h; für Finanzen und aufgeschobene Aufgaben - Tage/Wochen.

F: Wie kann ich späte Ereignisse verarbeiten?
A: Konfigurieren Sie' erlaubte Latenz' und 'late _ event' Alarm; spät - durch einen separaten Zweig (recompute/skip).

F: Kann der gesamte Telemetriefluss dedupliziert werden?
A: Ja, approximate-Filter (Bloom) am Rand, aber FP berücksichtigen und nicht auf kritische Geschäftseffekte anwenden.

F: Stört Dedup die Backfill?
A: Teilen Sie die Schlüsselräume ('Schlüssel # batch2025') oder deaktivieren Sie die Barriere für die Zeit des Backfills; Die TTL der Schlüssel sollte nur Online-Fenster abdecken.

17) Ergebnisse

Die Deduplizierung ist eine Komposition: der richtige Schlüssel, Fenster und Statusstruktur + Transaktionsmuster (Inbox/Outbox/UPSERT) und der bewusste Umgang mit Ordnung und verspäteten Ereignissen. Setzen Sie Barrieren, wo es am billigsten ist, sorgen Sie für Idempotenz in den Syncs, messen Sie' dedup _ hit _ rate' und testen Sie Replikate/Fails - so erhalten Sie „effektiv exactly-once“ ohne unnötige Latenzschwänze und Kosten.