{"id":33042,"date":"2025-05-22T11:16:38","date_gmt":"2025-05-22T09:16:38","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=33042"},"modified":"2025-05-26T12:55:29","modified_gmt":"2025-05-26T10:55:29","slug":"come-risolvere-il-dual-write-problem-nei-sistemi-distribuiti","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/backend-it\/come-risolvere-il-dual-write-problem-nei-sistemi-distribuiti\/","title":{"rendered":"Come risolvere il dual write problem nei sistemi distribuiti"},"content":{"rendered":"\n

In questo articolo, scoprirete come Unipol <\/a>ha affrontato l\u2019annoso tema del dual write problem<\/strong> nel contesto delle Architetture distribuite. Vengono presentate implementazioni di pattern come l’Outbox Table<\/strong>, il Saga<\/strong> e l’Idempotent Consumer,<\/strong>  gi\u00e0 rilasciate in produzione e che, gi\u00e0 da diversi mesi, garantiscono la protezione da messaggi e dati duplicati.<\/p>\n\n\n\n

Vedrete, infine, come l\u2019implementazione dell\u2019sdk del tool open source OpenTelemetry <\/strong>permetta di rendere osservabili integrazioni tra sistemi che non lo sono “out of the box\u201d, in particolare rendendo continuit\u00e0 la rilevazione delle tracce.<\/p>\n\n\n\n

Introduzione all\u2019architettura ad eventi e alle integrazioni asincrone<\/h2>\n\n\n\n

Nel contesto dei moderni sistemi informativi, l\u2019adozione di un\u2019architettura ad eventi rappresenta un passaggio cruciale per abilitare l\u2019evoluzione verso ecosistemi distribuiti, scalabili e reattivi. Le architetture monolitiche e sincrone, tipiche di molti sistemi legacy, presentano forti limitazioni in termini di scalabilit\u00e0, isolamento dei domini e resilienza agli errori. L\u2019approccio event-driven, al contrario, propone un modello di comunicazione decentrato, basato sull\u2019emissione e l\u2019ascolto di eventi tra servizi autonomi.<\/p>\n\n\n\n

In questo paradigma, i servizi producono eventi<\/strong> in risposta a cambiamenti di stato interni (ad esempio, la conferma di un ordine o la creazione di una nuova anagrafica) e altri servizi<\/strong> possono sottoscrivere questi eventi per reagire in modo asincrono.Questo consente di disaccoppiare i componenti, migliorando la manutenzione, la scalabilit\u00e0, la tolleranza ai guasti e l’evoluzione del sistema, permettendo di aggiungere nuovi consumer senza impatti sui componenti esistenti. Inoltre, gli eventi non devono necessariamente essere processati nell\u2019immediato: vengono accodati in broker (come Kafka, RabbitMQ, Azure Service Bus), il che consente retry e buffering naturali in caso di malfunzionamenti temporanei.<\/p>\n\n\n\n

L\u2019esperienza di Unipol mostra chiaramente come l\u2019introduzione di pattern evoluti come Outbox Table<\/strong>, Saga Coreografata<\/strong> e Idempotent Consumer  <\/strong>abbia abilitato il passaggio a un\u2019architettura asincrona , superando i limiti di quelle sincrone, in particolare nel contesto di eventuali fallimenti parziali<\/strong>.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

Cos\u2019\u00e8 il Dual Write Problem<\/h2>\n\n\n\n

Il \u201cdual write problem\u201d \u00e8 un difetto strutturale che emerge quando due operazioni non sono eseguite all\u2019interno di un\u2019unica transazione atomica<\/strong>. Questo significa che esiste la concreta possibilit\u00e0 che una delle due riesca<\/strong> mentre l\u2019altra fallisca<\/strong>, generando incoerenze<\/strong> tra lo stato dell\u2019applicazione e le informazioni condivise con altri sistemi.<\/p>\n\n\n\n

Un esempio classico \u00e8 il seguente: un sistema salva su database una nuova polizza cliente e successivamente pubblica un evento OrderCreated. Se per qualche ragione (timeout, crash, errore del broker) l\u2019evento non viene pubblicato, i sistemi a valle non riceveranno l\u2019informazione<\/strong>, generando uno stato globale incoerente. <\/p>\n\n\n\n

Nel mondo enterprise, dove i sistemi parlano tra loro continuamente \u2013 CRM, contabilit\u00e0, logistica, customer care \u2013 l\u2019affidabilit\u00e0 nella propagazione dei dati \u00e8 fondamentale. Il dual write \u00e8 uno dei principali nemici di questa affidabilit\u00e0. Nella presentazione Unipol, il problema viene affrontato in profondit\u00e0, mostrando come in un sistema distribuito il rischio di duplicati e inconsistenze sia concreto e spesso sottovalutato<\/strong>.<\/p>\n\n\n\n

A rendere tutto pi\u00f9 critico \u00e8 la difficolt\u00e0 di rilevare questi errori<\/strong>: un\u2019applicazione che non pubblica un evento, o che lo pubblica due volte, non segnala necessariamente un errore immediato, ma crea un debito informativo che pu\u00f2 emergere solo giorni dopo, ad esempio con un cliente che non riceve una notifica o con un ordine elaborato due volte. La coerenza eventuale, tanto celebrata nell\u2019architettura distribuita, deve essere supportata da meccanismi robusti che compensino queste debolezze.<\/p>\n\n\n\n

Il dual write problem \u00e8 quindi una trappola silenziosa<\/strong>, che va gestita con consapevolezza e strumenti appropriati. \u00c8 proprio da qui che nasce l\u2019esigenza dei pattern come Outbox<\/strong>, Saga<\/strong> e Idempotent Consumer<\/strong>, strumenti che vedremo nei prossimi capitoli e che, insieme all\u2019osservabilit\u00e0, rappresentano il cuore della strategia adottata da Unipol per costruire un\u2019infrastruttura veramente resiliente.<\/p>\n\n\n\n

Outbox Table Pattern: garantire transazioni atomiche<\/h2>\n\n\n\n

Per affrontare concretamente il problema del dual write, uno degli approcci pi\u00f9 efficaci e consolidati \u00e8 quello dell\u2019Outbox Table Pattern<\/strong>. Questo pattern nasce dall\u2019idea di spostare la responsabilit\u00e0 della comunicazione asincrona all\u2019interno della stessa transazione che coinvolge la scrittura dei dati principali.<\/p>\n\n\n\n

Immaginiamo un microservizio <\/a>che riceve un ordine e lo salva nel proprio database. Invece di inviare direttamente un evento \u201cordine creato\u201d su Kafka o su un altro message broker, il servizio scrive un messaggio all\u2019interno di una tabella di outbox<\/strong>, strutturalmente simile a una coda, ma residente nello stesso database. In questo modo, sia l\u2019ordine che l\u2019evento vengono persistiti all\u2019interno della stessa transazione atomica<\/strong>. Se qualcosa va storto, tutto viene rollbackato: ordine ed evento si annullano a vicenda, garantendo la coerenza.<\/p>\n\n\n\n

Un processo separato, detto spesso message relay o publisher<\/strong>, si occupa di leggere periodicamente la tabella outbox e inviare i messaggi al sistema di messaggistica esterno. Una volta che il messaggio \u00e8 stato correttamente inviato e ricevuto, l\u2019entry nella tabella pu\u00f2 essere marcata come \u201cspedita\u201d o rimossa. <\/p>\n\n\n\n

Nel caso di Unipol, questa strategia \u00e8 stata adottata per garantire la consistenza tra il dominio delle polizze e i sistemi esterni di notifica e rendicontazione. I team hanno implementato l\u2019outbox come parte integrante del modello di dominio, sfruttando framework come MyBatis per rendere la scrittura del messaggio un’operazione quasi trasparente dal punto di vista del codice.<\/p>\n\n\n\n

Una delle figure che meglio rappresenta questo pattern \u00e8 una pipeline di scrittura unica con ramo secondario asincrono<\/strong>, e potremmo suggerire come immagine una tabella SQL con colonna \u201cpayload\u201d affiancata a uno stream Kafka<\/strong>, collegati da un processore intermedio. Questa visualizzazione aiuta a comprendere che, pur essendo separata la logica di pubblicazione, la persistenza \u00e8 unica e affidabile.<\/p>\n\n\n\n

Outbox Table Pattern: garantire transazioni atomiche<\/h2>\n\n\n\n

In un mondo perfetto, ogni modifica al sistema avverrebbe in modo sincrono e atomico, garantendo che i dati siano sempre coerenti e affidabili. Tuttavia, nei sistemi distribuiti, questa garanzia \u00e8 difficile da mantenere. \u00c8 proprio in questo contesto che nasce l\u2019esigenza dell\u2019Outbox Table Pattern<\/strong>, una strategia capace di evitare il famigerato \u201cdual write problem\u201d grazie a un approccio semplice ma efficace.<\/p>\n\n\n\n

La logica dietro l\u2019Outbox<\/h3>\n\n\n\n

Il cuore del pattern consiste nel separare i dati da scrivere nei sistemi esterni (come un broker di messaggi) all\u2019interno di una tabella speciale chiamata outbox<\/em>, che vive nello stesso database transazionale dell\u2019entit\u00e0 da aggiornare. Cos\u00ec facendo, si evita di scrivere direttamente su un sistema esterno (ad esempio Kafka o RabbitMQ) all\u2019interno della stessa transazione del database principale, eliminando alla radice il rischio di inconsistenze dovute a errori parziali.<\/p>\n\n\n\n

Durante una transazione, l\u2019applicazione salva sia i dati di business sia il messaggio da inviare all\u2019esterno all\u2019interno della tabella outbox. Solo dopo che la transazione \u00e8 stata confermata, un componente separato \u2013 il message relayer<\/em> \u2013 legge i messaggi dalla tabella e li pubblica nel sistema esterno.<\/p>\n\n\n\n

Un esempio concreto da Unipol<\/h3>\n\n\n\n

Nel caso di Unipol, questo pattern \u00e8 stato adottato per sincronizzare eventi tra sistemi eterogenei, riducendo il rischio di eventi fantasma o perdite di messaggi nei processi core, ad esempio durante la generazione di contratti assicurativi o la notifica di eventi verso sistemi documentali. L\u2019approccio ha permesso non solo di migliorare l\u2019affidabilit\u00e0, ma anche di incrementare la visibilit\u00e0 delle operazioni effettuate, sfruttando audit trail e strumenti di osservabilit\u00e0 come Dynatrace.<\/p>\n\n\n\n

\"\"\/
Database per service<\/figcaption><\/figure>\n\n\n\n

Saga Pattern: l\u2019esecuzione ordinata di operazioni distribuite<\/h2>\n\n\n\n

Un altro tassello fondamentale nella gestione affidabile dei processi distribuiti \u00e8 il Saga Pattern<\/strong>, utilizzato per coordinare transazioni distribuite in assenza di un vero e proprio two-phase commit<\/em>. Quando un flusso di business si estende su pi\u00f9 microservizi, \u00e8 necessario garantire che ogni step venga eseguito nel giusto ordine, gestendo anche gli eventuali fallimenti intermedi.<\/p>\n\n\n\n

Cos\u2019\u00e8 una ‘saga’?<\/h3>\n\n\n\n

Una saga \u00e8 composta da una sequenza di operazioni locali, ciascuna delle quali pu\u00f2 essere compensata da un\u2019operazione inversa. In caso di errore, si avvia un processo di rollback parziale attraverso compensating transactions<\/em> che annullano le modifiche gi\u00e0 eseguite.<\/p>\n\n\n\n

Le saga possono essere coreografate<\/strong>, dove i partecipanti si coordinano tramite eventi, oppure orchestrate<\/strong>, dove un servizio centrale controlla l\u2019intero flusso. In contesti di alta resilienza, la coreografia \u00e8 spesso preferita per evitare colli di bottiglia e single point of failure.<\/p>\n\n\n\n

L\u2019esperienza di Unipol<\/strong><\/h3>\n\n\n\n

In scenari come la gestione di polizze multicanale o la notifica di cambiamento stato, Unipol ha adottato saghe coreografate per mantenere consistenza e tracciabilit\u00e0, soprattutto in flussi critici dove l\u2019ordine delle operazioni \u00e8 fondamentale ma deve essere mantenuto in ambienti eterogenei.<\/p>\n\n\n\n

Questa architettura ha dimostrato di essere particolarmente robusta in condizioni di carico elevato o in presenza di integrazioni asincrone con terze parti, dove le latenze possono variare significativamente.<\/p>\n\n\n\n

Idempotent Consumer Pattern: protezione contro i messaggi duplicati<\/h2>\n\n\n\n

Anche con l\u2019adozione di buone pratiche, il rischio di ricevere pi\u00f9 volte lo stesso messaggio \u00e8 sempre presente. \u00c8 qui che entra in gioco il Idempotent Consumer Pattern<\/strong>, una strategia che permette a un sistema di elaborare lo stesso messaggio pi\u00f9 volte senza effetti collaterali.<\/p>\n\n\n\n

Perch\u00e9 l\u2019idempotenza \u00e8 fondamentale<\/h3>\n\n\n\n

In un sistema distribuito, la duplicazione dei messaggi pu\u00f2 avvenire per molteplici motivi: retry automatici, errori di rete, o crash temporanei del consumer. Se non gestiti correttamente, questi duplicati possono portare a errori logici come la duplicazione di ordini, la sovrascrittura di dati o l\u2019attivazione ripetuta di operazioni.<\/p>\n\n\n\n

Per rendere un consumer idempotente, \u00e8 comune salvare un identificatore univoco per ogni messaggio elaborato e controllare la presenza dello stesso prima di applicare qualsiasi cambiamento. In alternativa, alcune architetture optano per operazioni \u201csafe by design\u201d, che non hanno effetti collaterali anche se ripetute.<\/p>\n\n\n\n

L\u2019approccio di Unipol<\/h3>\n\n\n\n

Unipol ha adottato un sistema di deduplica per gli eventi pi\u00f9 critici, salvando il message ID<\/em> in tabelle di log e ignorando messaggi gi\u00e0 elaborati. Questa tecnica si \u00e8 dimostrata fondamentale per garantire l\u2019integrit\u00e0 nei flussi di notifica e nella propagazione di eventi interni tra sistemi legacy e moderni.<\/p>\n\n\n\n

\"\"\/
Patterns in action (SAGA + Transactional Outbox + Idempotent Consumer)<\/figcaption><\/figure>\n\n\n\n

Osservabilit\u00e0 con OpenTelemetry e Dynatrace<\/h2>\n\n\n\n

Quando si progettano architetture distribuite complesse, implementare i pattern corretti non basta. Per garantire affidabilit\u00e0, bisogna vedere<\/em> cosa succede nel sistema, anticipare i problemi, identificare colli di bottiglia e analizzare i flussi in modo trasparente. \u00c8 qui che l\u2019osservabilit\u00e0<\/strong> gioca un ruolo chiave, permettendo di correlare eventi, transazioni e performance attraverso l\u2019intera infrastruttura.<\/p>\n\n\n\n

L\u2019osservabilit\u00e0 come componente architetturale<\/h3>\n\n\n\n

In sistemi che adottano pattern come Outbox o Saga, il tracciamento di un singolo evento che attraversa servizi diversi pu\u00f2 diventare complesso. Per questo, Unipol ha integrato strumenti come OpenTelemetry<\/strong>, un framework open-source per la raccolta di metriche, log e tracce distribuite, e Dynatrace<\/strong>, una piattaforma di monitoraggio avanzata con funzionalit\u00e0 di AIOps e tracciamento automatico delle dipendenze.<\/p>\n\n\n\n

OpenTelemetry permette di standardizzare la raccolta dei dati da applicazioni e servizi, mentre Dynatrace si occupa della visualizzazione, della correlazione automatica e dell\u2019analisi predittiva. Insieme, questi strumenti offrono una visione in tempo reale delle performance del sistema, rilevando anomalie, ritardi nei flussi delle saghe o tentativi ripetuti di elaborare eventi duplicati.<\/p>\n\n\n\n

L\u2019applicazione in Unipol<\/h3>\n\n\n\n

Nei flussi core come quelli di generazione documentale o di notifica eventi verso i partner, Unipol ha utilizzato tracing distribuito<\/strong> per mappare ogni step dell\u2019elaborazione. Questo ha consentito di isolare rapidamente le cause di latenza, verificare se un outbox non veniva processato o se un servizio compensativo non si attivava correttamente. La sinergia tra metadati semantici raccolti da OpenTelemetry e l\u2019intelligenza artificiale di Dynatrace ha permesso di costruire un sistema non solo osservabile, ma anche capace di autodiagnosi e interventi proattivi.<\/p>\n\n\n\n

\"\"\/
osservabilit\u00e0 su schema dell’applicazione<\/figcaption><\/figure>\n\n\n\n

Conclusioni: lezioni apprese e prospettive future<\/h2>\n\n\n\n

L\u2019esperienza di Unipol dimostra che affrontare il dual write problem<\/em> \u00e8 una sfida concreta, ma anche una grande opportunit\u00e0 per migliorare l\u2019affidabilit\u00e0 dei sistemi distribuiti. Attraverso l\u2019adozione di pattern architetturali robusti e strumenti di osservabilit\u00e0, \u00e8 possibile costruire piattaforme resilienti, scalabili e trasparenti.<\/p>\n\n\n\n

L\u2019Outbox Table Pattern<\/strong> ha permesso di isolare la logica transazionale dalla comunicazione asincrona, riducendo il rischio di inconsistenze nei messaggi inviati. Il Saga Pattern<\/strong>, applicato in versione coreografata, ha favorito la gestione di processi distribuiti con un grado elevato di flessibilit\u00e0 e recuperabilit\u00e0. L\u2019approccio idempotente<\/strong> ha offerto un\u2019ulteriore barriera contro i problemi derivanti da retry o duplicazioni, rendendo i consumer pi\u00f9 sicuri e prevedibili.<\/p>\n\n\n\n

Ma \u00e8 grazie all\u2019introduzione di OpenTelemetry<\/strong> e Dynatrace<\/strong> che queste soluzioni hanno potuto esprimere tutto il loro potenziale. Solo con una visibilit\u00e0 profonda e continua dei sistemi \u00e8 possibile garantire un funzionamento fluido e tempestivamente correggere le anomalie.<\/p>\n\n\n\n

\n\n\n\n
\"\"<\/figure><\/div><\/div>

Angelo Manzione<\/a><\/h2>

Head of Enterprise & Cloud Solution Architecture presso Gruppo Unipol<\/p>

Angelo is a specialized software engineer, with a solid work experience. His objective way of facing problems and his ability to see innovative solutions from a new point of view are some of his best skills.<\/div>