Issue 10008 · Sistemi distribuiti
Transactional Outbox: pubblicare eventi senza perdere coerenza
Quando un servizio deve aggiornare il proprio database e notificare altri sistemi, il punto non è solo “mandare il messaggio”: è farlo in modo affidabile e misurabile.
· 5 min
Obiettivo
Progettare un flusso affidabile di pubblicazione eventi quando un servizio deve aggiornare il proprio database e pubblicare un messaggio senza affidarsi a transazioni distribuite.
Cosa fare in pratica
Se il tuo servizio è il System of RecordGlossarioSystem of RecordIl sistema autorizzato a decidere il valore corrente di uno specifico fatto di business.Apri la voce completa per un dato, la regola pratica è semplice: scrivi prima il dato e l’eventoGlossarioEventoUna dichiarazione durevole che qualcosa di significativo è già accaduto.Apri la voce completa nella stessa transazione locale, poi pubblica l’evento in modo asincrono dalla outbox. In questo modo non stai tentando di coordinare database e broker con una transazione distribuita, ma rendi persistente l’intenzione di pubblicazioneGlossarioPubblicazioneL’azione esplicita che rende disponibile ai lettori una issue approvata.Apri la voce completa insieme allo stato che l’ha generata. Il flusso tipico è: 1) il servizio riceve una richiesta, 2) aggiorna il proprio database, 3) inserisce un record outbox con payload, tipo evento e metadati, 4) un publisher legge la outbox e invia il messaggio al broker, 5) dopo l’ack aggiorna lo stato del record outbox. Questo approccio è utile quando altri sistemi dipendono da un evento affidabile per aggiornare viste, avviare processi o sincronizzare stati. Da architetto, la domanda chiave non è “possiamo pubblicare l’evento subito?”, ma “cosa succede se il servizio muore tra commit DB e publish?”. La outbox esiste proprio per chiudere quel buco operativo.
Trade-off da valutare
Il vantaggio principale è l’affidabilità: riduci il rischio di perdere eventi e separi la consistenza del dato locale dalla consegna al broker. Ottieni anche un punto di osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa migliore, perché puoi monitorare eventi in coda, ritardi di pubblicazione e retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa. Il costo è che introduci più componenti e più stato operativo. Devi gestire polling o change data capture, deduplica lato consumer, retention della tabella outbox, idempotenzaGlossarioIdempotenzaLa proprietà per cui ripetere un’operazione non produce effetti aggiuntivi indesiderati.Apri la voce completa dei consumatori e possibili ritardi tra commit e pubblicazione. Inoltre, il sistema non diventa “sincrono”: l’evento può arrivare dopo qualche secondo, quindi il design deve accettare consistenza eventuale. In pratica, il pattern conviene quando la perdita di un evento è più grave della latenza aggiunta. Se invece il caso d’uso richiede una risposta immediata e l’effetto esterno è semplice da ricostruire, può bastare un altro approccio, ma va deciso esplicitamente, non per abitudine.
Esempio enterprise realistico
Immagina un OMS in un contesto e-commerce. Quando un ordine passa da “creato” a “confermato”, l’OMS è il System of Record per quello stato. Nella stessa transazione aggiorna il proprio database e salva un record outbox con l’evento OrderConfirmed. Un publisher legge la outbox e pubblica l’evento verso ERP, motore di fulfillment e canaleGlossarioCanaleUn formato o una destinazione attraverso cui una issue raggiunge il lettore.Apri la voce completa digitale. L’ERP usa l’evento per contabilizzare, il fulfillment per preparare la spedizione, il canale digitale per aggiornare la vista cliente. Se il broker è temporaneamente indisponibile, l’ordine resta comunque confermato nel sistema autorevole e l’evento viene ritentato senza perdere il dato. Qui la discussione architetturale utile non è solo tecnica: bisogna chiarire chi possiede la verità sull’ordine, quali sistemi consumano una vista derivata e quali team accettano la latenza di propagazione.
Per approfondire
Fonti esterne autorevoli per approfondire il pattern e le sue implicazioni operative. • Transactional Outbox - microservices.io - https://microservices.io/patterns/data/transactional-outbox.html • Designing Data-Intensive Applications - Martin Kleppmann - https://dataintensive.net/