Eventi fuori ordine in un’integrazione: come evitare che un aggiornamento vecchio sovrascriva dati nuovi

Un’integrazione riceve prima un aggiornamento dell’indirizzo e poi un evento che indica che il cliente ha ancora quello precedente. Se applica i messaggi nell’ordine di arrivo, il record finisce per essere obsoleto. Il secondo evento non è necessariamente falso: può essere valido, ma riferirsi a un cambiamento avvenuto prima.

Gestire gli eventi fuori ordine significa distinguere il momento in cui è avvenuta una modifica da quello in cui è stata ricevuta e stabilire quale fonte di informazioni può determinare quale dato deve prevalere. Non esiste una regola universale basata sulla data: la scelta dipende dal tipo di evento, da come vengono generati i dati e dal sistema che ne è responsabile.

Perché gli eventi arrivano fuori ordine

Una coda, un webhook o un processo di integrazione possono introdurre un ritardo tra la generazione di un evento e la sua elaborazione. Le consegne possono essere ripetute, i messaggi elaborati in parallelo oppure instradati su percorsi con latenze diverse. Di conseguenza, due eventi relativi alla stessa entità possono arrivare in un ordine diverso da quello di creazione. Possono anche essere duplicati se il mittente riprova dopo non aver ricevuto una conferma.

L’ordine può essere mantenuto all’interno di un flusso specifico, ma non tra flussi distinti. Per esempio, le modifiche di un account potrebbero essere distribuite su più partizioni, mentre quelle dei relativi ordini vengono elaborate separatamente. Non dare per scontato che una coda o un’API garantiscano un ordinamento globale, a meno che questa proprietà sia documentata e rispettata nel percorso effettivo.

L’impatto dipende dal contenuto:

• Un evento con stato completo descrive le condizioni di un record in un determinato momento. Se applicato in ritardo, uno stato precedente può sostituire campi aggiornati più di recente.
• Un evento delta descrive una modifica, per esempio l’aggiunta di un’etichetta o l’incremento di un contatore. Scartarlo perché sembra più vecchio potrebbe eliminare una modifica legittima, non ancora applicata.

Prima di scegliere una regola, verifica se i messaggi contengono stati completi, modifiche parziali o una combinazione dei due. La strategia corretta per un profilo potrebbe non essere adatta a un’operazione finanziaria o a una transizione di ordine.

Ora di ricezione, ora dell’evento e sequenza di business

L’ora di ricezione indica quando il sistema che consuma il messaggio lo ha osservato. È utile per misurare i ritardi e ordinare i messaggi ricevuti da quel consumatore, ma non dimostra quando è avvenuta la modifica originale.

L’ora dell’evento dovrebbe riflettere il momento in cui la modifica è avvenuta o è stata registrata. Può aiutare nella diagnosi, ma dipende dall’orologio, dalla precisione e dalle convenzioni del mittente. Due sistemi possono avere orologi non sincronizzati; inoltre, un evento generato durante una ripresa può riportare un’ora che non rappresenta con esattezza l’ordine di business. Una data più recente, da sola, non prova quale evento debba prevalere.

La sequenza di business esprime l’ordine rilevante per quella specifica entità: per esempio, la versione 12 di una scheda segue la versione 11, oppure un’operazione viene confermata dopo un’altra. Se il sistema di origine fornisce una versione monotona o un numero di sequenza affidabile e associato alla stessa entità, di solito è un indicatore più solido dell’ora. Verificane l’ambito: il valore potrebbe azzerarsi, essere locale a un processo o non permettere di confrontare modifiche di entità diverse.

Registra questi valori separatamente. Non riutilizzare un unico campo chiamato «data» per stabilire la precedenza, misurare i ritardi e conservare le informazioni di audit: ogni scopo richiede un’interpretazione chiara.

Come riconoscere un aggiornamento obsoleto senza perdere modifiche valide

Un aggiornamento è obsoleto solo rispetto a una regola definita e allo stato attuale conosciuto dal consumatore. Per esempio, se quest’ultimo conserva la versione 18 di un cliente e riceve uno stato completo della versione 16, può rifiutarlo perché precedente. Non dovrebbe invece scartare automaticamente un delta valido solo perché ha un timestamp inferiore: potrebbe aggiungere un dato assente nell’evento successivo.

Per valutare ogni messaggio, controlla:

• Identità e ambito: a quale entità, campo o aggregato si riferisce. Due modifiche potrebbero essere indipendenti e non richiedere una scelta tra l’una e l’altra.
• Tipo e versione: se contiene uno stato completo o un delta e se la sua sequenza è confrontabile con quella già applicata.
• Precondizioni: se la transizione è valida rispetto allo stato attuale. Un cambio a «spedito» non dovrebbe riportare senza spiegazioni un ordine già «consegnato» a uno stato precedente.
• Autorità: quale sistema può determinare il valore di quel campo. Un aggiornamento del profilo e una correzione proveniente dal sistema master non hanno necessariamente lo stesso peso.

Il confronto e la scrittura devono essere coerenti. Se due consumatori leggono la versione 16 e provano entrambi a salvare modifiche, un controllo eseguito prima della scrittura potrebbe diventare obsoleto. Usa un aggiornamento condizionato alla versione osservata, o un’operazione equivalente nell’archivio dati: il consumatore potrà così rilevare che il record è cambiato prima della conferma.

Criteri per risolvere i conflitti

Privilegia l’indicatore più affidabile che sia effettivamente disponibile; non inventare una gerarchia usando campi che non garantiscono l’ordinamento. I criteri seguenti possono essere combinati, purché il loro significato sia documentato:

1. Versione o sequenza per entità: accetta lo stato completo se la versione avanza e ignora una versione già applicata o precedente. Definisci come gestire salti, azzeramenti e versioni mancanti.
2. Stato e transizione consentita: verifica la modifica rispetto a una macchina a stati o alle regole di business. Una transizione non valida dovrebbe richiedere una verifica, non trasformarsi silenziosamente in un aggiornamento.
3. Autorità per campo: assegna ogni dato a un sistema responsabile. Se due fonti possono modificare legittimamente lo stesso campo, stabilisci una politica esplicita, come una revisione o una priorità concordata, invece di affidarti alla regola improvvisata dell’«ultimo messaggio ricevuto».
4. Confronto del contenuto: applica delta idempotenti quando possibile ed evita di sostituire un intero record con un messaggio parziale. Se l’evento non chiarisce che cosa è cambiato, consulta la fonte attendibile prima di sovrascrivere.

La regola «vince l’ultima scrittura» può essere accettabile per campi poco critici, se gli orologi e la politica sono sufficientemente controllati. Non è una regola neutrale: può cancellare modifiche valide e nascondere conflitti. Per le decisioni sensibili, è preferibile conservare entrambe le versioni o impedire la risoluzione automatica.

Cosa fare se non esiste una sequenza affidabile

Se il mittente non fornisce una versione confrontabile, non cercare di ricostruire l’ordine esatto usando l’ora di ricezione. Scegli una risposta proporzionata alle conseguenze di un eventuale errore:

• Consultare lo stato attuale nel sistema di origine prima di aggiornare, se è disponibile un’API di lettura affidabile. In questo modo si dipende meno da un messaggio in ritardo, ma occorre considerare che lettura e scrittura possono entrare in competizione con modifiche successive.
• Applicare solo i campi indipendenti se l’evento indica con chiarezza che cosa ha modificato. Conserva gli altri valori ed evita di sostituire l’intero record.
• Mettere da parte il conflitto per una riconciliazione quando mancano informazioni o il dato è importante. Conserva il messaggio, l’entità e il motivo della decisione, così che il caso possa essere esaminato.
• Definire una priorità della fonte quando il business ha stabilito quale sistema prevale su un dato. Comunica la regola ai team e rivedi le eccezioni.

Una coda di revisione o una consultazione successiva non devono diventare un limbo invisibile. Stabilisci chi gestisce i casi, come vengono ritentati e quale indicatore ne segnala la risoluzione. Se non è possibile decidere automaticamente, dichiarare l’incertezza è più sicuro che presentare come aggiornato un dato dubbio.

Test e registri per verificare il comportamento

Metti alla prova il contratto d’integrazione, non solo il percorso ideale. Per la stessa entità, invia due modifiche in ordine inverso, ripeti un evento già elaborato, ritardane uno durante un nuovo tentativo e fai in modo che due aggiornamenti vengano scritti quasi contemporaneamente. Se possibili nel sistema di origine, includi versioni uguali, mancanti o inattese.

Verifica non solo il valore finale, ma anche la decisione: accettato, ignorato perché duplicato o obsoleto, unito, messo da parte oppure rifiutato per una transizione non valida. Controlla che i messaggi ripetuti non producano effetti aggiuntivi e che gli eventi validi non vadano persi a causa di una regola basata soltanto sulle date.

Registra l’identificativo dell’evento, l’entità, la fonte, la versione o sequenza disponibile, l’ora dell’evento e quella di ricezione, la versione precedente e successiva e il motivo della decisione. Evita di includere nei registri dati personali non necessari. Monitora l’età dei messaggi e il volume dei conflitti: un aumento può indicare ritardi, nuovi tentativi o un cambiamento nel sistema mittente, non necessariamente un guasto del consumatore.

Decisioni da prendere prima di avviare l’integrazione

• Ogni messaggio rappresenta uno stato completo, un delta o entrambi i tipi?
• Quale campo stabilisce la precedenza e chi ne garantisce l’ambito e la continuità?
• Quale sistema è responsabile di ciascun dato e quali modifiche può accettare ogni fonte?
• Come si evitano duplicati e scritture concorrenti che invalidano un controllo?
• Che cosa accade in caso di sequenze mancanti, transizioni non valide e conflitti ambigui?
• Chi esamina i casi messi da parte e come si misura il tempo necessario per risolverli?

In pratica, occorre usare l’indicatore d’ordine più affidabile disponibile, limitare ogni evento ai dati che modifica davvero e rendere esplicita l’incertezza. Così è possibile riconoscere un messaggio in ritardo senza scartare alla cieca modifiche legittime né permettere a un aggiornamento vecchio di sovrascrivere lo stato corrente.