Deduplicazione degli eventi

1) Perché è necessaria la deduplicazione

• sono violati gli invarianti (doppi prelievi, e-mail/SMS ripetuti, ordine «due volte creato»);
• Costi in aumento (ripetuti record/elaborazioni)
• L'analista si distorce.

Lo scopo della deduplicazione è quello di fornire un unico effetto osservabile per le ripetute di trasporto consentite, spesso insieme all'idipotenza.

2) Dove posizionare la deduplicazione (livelli)

1. Edge/API gateway - ritaglia le riprese esplicite in «Idempotency-Keu »/corpo + firma.
2. Broker/stream - deduplicazione logica per chiave/sequenza, coalescing in caso di errore (meno a causa del costo).
3. Il ricevitore eventi (consumer) è il punto principale: Inbox/tabella chiavi/cache.
4. Sink (BD/cash) - Chiavi univoche/UPSERT/versioni/compressione.
5. L'ETL/analisi è un dedotto della finestra del tempo e della chiave degli store invertebrati.

Regola: prima possibile, ma tenendo conto del costo dei falsi funzionamenti e della necessità di repliche.

3) Chiavi di deduplicazione

3. 1 Naturali (preferibilmente)

`payment_id`, `order_id`, `saga_id#step`, `aggregate_id#seq`.
Garantiscono stabilità e senso.

3. 2 Composti

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

3. 3 Impronta (fingerprint)

Hash determinata sottoinsieme di campi (normalizzare ordine/registro) opzionale'HMAC (secret, payload) '.

3. 4 Sequenze/versioni

Monotoni «seq» per aggregate (blocco/versioning ottimistico).

Anti-pattern: «UUID random» senza relazione con l'entità aziendale - non è possibile.

4) Finestre temporanee e ordine

La finestra di deduplicazione è il periodo in cui un evento può ripetersi (in genere 24-72h; per la finanza, più a lungo).
Out-of-order - Consente il ritardo (lateness). Nelle cornici di flusso - event time + watermarks.
Sliding/Fix-window deadup: "La chiave è stata vista negli ultimi minuti N? ».
Sequence-aware: se «seq» è l'ultimo elaborato, è una ripresa/ripetizione.

5) Strutture dati e implementazioni

5. 1 Contabilità esatta (exact)

REDIS SET/STRING + TTL: 'SETNX key 1 EX 86400' «Per la prima volta, lavoriamo, altrimenti, SKIP».
LRU/LFU cache (in-proc) - Veloce, ma volatile è migliore solo come prima barriera.
SQL indici unici + UPSERT: «inserisci o aggiorna» (effetto idipotente).

5. 2 Strutture ravvicinate (probabilistic)

Bloom/Cuckoo filter: memoria a basso costo, possibili falsi funzionamenti (false positive). Adatto per il drop rumoroso (ad esempio, la telemetria), non per la finanza/ordine.
Count-Min Sketch - Valutazione delle frequenze per la protezione dalle prese a caldo.

5. 3 Stati di flusso

Kafka Streams/Flink: keyed state store con TTL, la chiave nella finestra; checkpoint/restore.
Watermark + allowed lateness - Controlla la finestra degli eventi in ritardo.

6) Pattern transazionali

6. 1 Inbox (tabella in ingresso)

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;

La ripetizione vedrà la registrazione e non ripeterà l'effetto.

6. 2 Outbox

La registrazione aziendale e l'evento in una singola transazione vengono assegnati a un broker. Non elimina la presa dal consumatore, ma esclude i buchi.

6. 3 Indici univoci/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 Versioning degli apparecchi

L'evento è valido se è 'event'. version = aggregate. version + 1`. Altrimenti, ripresa/ripetizione/conflitto.

7) Deadup e broker/striam

7. 1 Kafka

Idempotent Producer riduce le riprese all'ingresso.
Le transazioni permettono la comunicazione atomica offset + output.
Compattion: memorizza l'ultimo valore per key - deadup/coalizione post-fattura (non per i pagamenti).
Consumer-side: state store/Redis/DB per le chiavi della finestra.

7. 2 NATS / JetStream

Ack/rarità → at-least-once. Deadup nel consumatore (Inbox/Redis).
sequence/durabot del consumatore semplificano l'individuazione delle ripetizioni.

7. 3 Code (Rabbit/SQS)

Visibility timeout + reimpostazione di una chiave + dashboard.
SQS FIFO con «MessageGroupId »/« DeduplicationId» aiuta, ma le finestre TTL sono limitate dal provider - conserva le chiavi più a lungo se il business richiede.

8) Storage e analisi

8. 1 ClickHouse/BigQuery

"ORDER BY key, t'e" argMax "/" anyLast "con una condizione.

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

Oppure un livello di eventi «univoci» materializzato (merge per chiave/versione).

8. 2 Logi/telemetria

Permettiamo l'apploximate-deadup (Bloom) su ingest per risparmiare rete/disco.

9) Rielaborazione, repliche e backfill

Le chiavi di deduplicazione devono essere superate dalle repliche (TTL).
Per backfill, utilizzare lo spazio delle chiavi con la versione («key # source = batch2025») o le singole «prugne» per non interferire con la finestra online.
Memorizza gli artefatti di risultato (hash/versione) - Questo accelera «fast-skip» sulle ricorrenze.

10) Metriche e osservabilità

«dedup _ hit _ total »/« dedup _ hit _ rate» è la percentuale di prese catturate.
«dedup _ fp _ rate» per i filtri probabilistici.
'window _ size _ seconds'è reale (per telemetry late arrivals).
`inbox_conflict_total`, `upsert_conflict_total`.
`replayed_events_total`, `skipped_by_inbox_total`.
Profili tenant/key/type: dove ci sono più riprese e perché.

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

11) Sicurezza e privacy

Non mettere il PII nella chiave; Usa hash/alias.
La firma dell'impronta è HMAC (secret, canonical _ payload) per evitare conflitti/contraffazione.
Concordare con la compilazione (GDPR retensh).

12) Prestazioni e costi

In-proc LRU ≪ Redis ≪ SQL per latenza/costo per operazione.
Redis: economico e veloce, ma tenere conto della quantità di chiavi e TTL; «tenant/hash».
SQL: costoso a p99, ma offre una garanzia e una verifica severe.
Filtri probabilistic: molto economico, ma possibile FP - utilizzare dove «SKIP in eccesso» non è critico.

13) Anti-pattern

«Kafka exactly-once non ha bisogno di una chiave». Ho bisogno di uno slot sink/business.
TTL troppo breve per le chiavi delle repliche/ritardo per la ripresa.
Global single deadup store → hotspot e SPOF; non è scardinato per tenant/chiave.
Deadup solo nella memoria - Perdita del processo = ondata di riprese.
Bloom per denaro/ordini - false positive priverà l'operazione legittima.
Canonizzazione non coerente payload: hash diversi per messaggi identici.
Ignora out-of-order - Gli eventi recenti sono contrassegnati in modo errato.

14) Assegno foglio di implementazione

• Definire la chiave naturale (o la chiave composta/impronta).
• Impostare la finestra di controllo e il criterio lateness.
• Selezionare il livello (io): edge, consumer, sink; Prevedere un charding.
• Implementare Inbox/UPSERT; per i flussi - keyed state + TTL.
• Se si desidera una barriera approximate - Bloom/Cuckoo (solo domini non ritrici).
• Configurare le repliche di compatibilità (TTL) nella finestra di replica/backfill.
• Metriche dedup _ hit _ rate, conflitti e lame delle finestre; dashboard per-tenant.
• Game Day: timeout/retrai, repliche, out-of-order, caduta della cache.
• Documentare la canonizzazione payload e la versioning delle chiavi.
• Eseguire test di carico su chiavi hot e finestre lunghe.

15) Esempi di configurazione/codice

15. 1 Redis SETNX + TTL (barriera)

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 (dedotto nella finestra)

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 (keyed state + TTL, pseudo)

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

15. 5 gateway NGINX/API (Idempotency-Key su edge)

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

16) FAQ

Q: Quali sono le opzioni di deducibilità o idempotenza pura?
A: In genere, il deadup è un «filtro» rapido (risparmio), l'idipotenza garantisce l'effetto corretto.

Q: Quale TTL mettere?
A: il tempo massimo possibile per la ricarica + scorta. Tipico 24-72h; per le attività finanziarie e posticipate - giorni/settimane.

Q: Come gestire gli eventi tardivi?
A: Regolare allowed lateness e l'allarme late _ event; tardo - attraverso un ramo separato (recompute/skip).

Q: È possibile deduplicare l'intero flusso di telemetria?
A: Sì, filtri approximate (Bloom) su edge, ma tenere conto di FP e non applicare agli effetti aziendali critici.

Deadup interferisce con il backphill?
A: Separa gli spazi delle chiavi («key # batch2025») o disattiva la barriera durante il backfill; Le chiavi TTL devono coprire solo le finestre online.

17) Riepilogo

La deduplicazione è una composizione: chiave corretta, finestra e struttura di stato + pattern transazionali (Inbox/Outbox/UPSERT) e lavoro consapevole con l'ordine e gli eventi in ritardo. Posiziona le barriere dove è meno costoso, assicuri l'idampotenza nei picchi, misura'dedup _ hit _ rate ', e prova le repliche/feel - in modo da ottenere «effettivamente exactly-oncè» senza troppe code di latitanza e costo.