Issue 10031
CDC: integrare i cambiamenti senza legare l’integrazione alla scrittura
Quando usare il Change Data Capture per esporre modifiche confermate, e dove invece introduce complessità da governare con attenzione.
· 5 min
Obiettivo
Valutare e progettare il Change Data Capture per esporre cambiamenti confermati del database senza accoppiare l’integrazione ai percorsi di scrittura applicativi.
Capire cosa fa davvero il CDC
Il Change Data Capture serve a leggere i cambiamenti già confermati nel database e renderli disponibili ad altri sistemi. In pratica, ti permette di integrare senza modificare subito il percorso di scrittura applicativo, cosa utile quando hai legacy, vincoli di rilascio o più consumerGlossarioConsumerUn sistema, team o processo che dipende da dati, eventi o comportamenti esposti da un altro sistema.Apri la voce completa da servire. La decisione architetturaleGlossarioDecisione architetturaleUna scelta progettuale significativa il cui contesto e i cui effetti devono restare comprensibili nel tempo.Apri la voce completa importante è questa: il CDC non produce automaticamente eventi di dominioGlossarioDominioLa parte del mondo reale, del business o dell’organizzazione che un sistema deve supportare.Apri la voce completa. Produce cambiamenti tecnici del dato persistito. Se ti serve una semantica di business, devi aggiungere un livello di modellazione e di interpretazione, altrimenti i consumer si ritrovano a consumare insert, update e delete con significato solo parziale. Come architetto, dovresti chiarire subito tre cose: quale fonte legge il CDC, quale garanzia di ordine ti serve e come gestirai snapshot iniziale, lag e evoluzione dello schema. Sono spesso questi i punti che determinano il successo o il fallimento della soluzione.
Trade-off principali da esplicitare
Il vantaggio del CDC è chiaro: disaccoppia l’integrazione dal codice applicativo e riduce l’impatto sui sistemi esistenti. È spesso la scelta più pragmatica quando non puoi introdurre eventi in scrittura in tempi brevi. I costi però non sono marginali. Il consumer osserva il cambiamento dopo il commit, quindi il CDC non deve essere assunto come meccanismo di consistenza sincrona: il lag operativo va considerato esplicitamente. Inoltre devi gestire ordering, duplicati, retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa, schema evolution e cancellazioni fisiche o logiche. Se il database contiene dati sensibili, il CDC può anche amplificare il problema di exposure verso downstream che non avrebbero dovuto vedere certi campi. Il punto di equilibrio è questo: CDC va bene per replica, integrazione, analytics e sincronizzazione di sistemi, ma non è automaticamente il migliore veicolo per la logica di dominio. Quando i consumer iniziano a dipendere dal comportamento del log, stai trasformando una scelta infrastrutturale in un contratto applicativo molto più fragile.
Esempio enterprise realistico
Immagina una società retail con un ERP legacy e un nuovo data platformGlossarioPlatformUn insieme gestito di capability riusabili che permette ai team di consegnare e operare soluzioni tramite interfacce definite.Apri la voce completa team che deve alimentare near-real-time reporting, fraud detection e un motore di raccomandazione. Il team non può riscrivere subito l’applicazione core, ma deve rendere visibili gli ordini confermati quasi in tempo reale. In questo scenarioGlossarioScenarioUna situazione concreta usata per testare come un design o una decisione si comporta.Apri la voce completa il CDC è sensato per pubblicare le modifiche del database verso un bus o una piattaforma di streaming. Però servono guardrail: snapshot iniziale coerente per riallineare i consumer, mapping chiaro dei campi sensibili, convenzioni per identificare update e delete, e una strategia per le evoluzioni dello schema senza rompere i consumer. Se il sistema antifrode richiede un significato di business preciso, ad esempio "ordine confermato" o "pagamento autorizzato", conviene non affidarsi solo al CDC del record. Meglio arricchire o derivare un eventoGlossarioEventoUna dichiarazione durevole che qualcosa di significativo è già accaduto.Apri la voce completa di dominio a partire da quel cambiamento persistito, oppure separare chiaramente i casi d’uso di replica da quelli di orchestrazione.
Per approfondire
Fonti esterne autorevoli per approfondire il Change Data Capture e i suoi trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa architetturali. • Debezium Documentation - Red Hat - https://debezium.io/documentation/ • Database Replication - Microsoft Learn - https://learn.microsoft.com/en-us/sql/relational-databases/replication/ • Designing Data-Intensive Applications - Martin Kleppmann - https://dataintensive.net/