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.

Separare il cambiamento tecnico del database dalla semantica di business consumata a valle

Obiettivo

Valutare e progettare il Change Data Capture per esporre cambiamenti confermati del database senza accoppiare l’integrazione ai percorsi di scrittura applicativi.

practice

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ù consumer 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-offs

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.

enterprise-example

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.

references

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/

Da ricordare

Il CDC è ottimo per integrare cambiamenti confermati senza toccare il percorso di scrittura, ma va progettato come contratto tecnico con attenzione a semantica, ordering, snapshot, schema evolution e protezione dei dati.

Per la prossima riunione

Se dovessi introdurre il CDC in questo sistema, quale decisione useresti per separare i cambiamenti tecnici del database dagli eventi di business che i consumer si aspettano?

Una domanda per te