Quando cambia un prodotto, può cambiare anche il modo in cui rappresenta i dati: un campo viene rinominato, un’entità viene suddivisa o viene introdotta una nuova regola di business. La decisione non è solo tecnica. Occorre scegliere se aggiornare i record esistenti, adattare i dati ogni volta che vengono consultati oppure mantenere entrambi i formati durante una transizione.
La domanda utile è quando migrare i dati e quando trasformarli in lettura. La risposta dipende da chi utilizza le informazioni, dal livello di coerenza richiesto dal prodotto e dal costo di manutenzione della soluzione. Nessun approccio è sempre il migliore: l’obiettivo è rendere espliciti i compromessi e definire come verificare che funzionino.
Cosa cambia con ciascun approccio
Una migrazione persistente modifica i dati archiviati affinché rispettino il nuovo modello. Può essere eseguita in un’unica operazione controllata o in batch, a seconda del volume, dell’infrastruttura e dei requisiti di disponibilità. In seguito, le query utilizzano la nuova rappresentazione, anche se durante la transizione potrebbe essere necessario riconoscere i record più vecchi.
La trasformazione in lettura conserva i dati originali e li adatta al momento della restituzione. Un livello di accesso, un servizio o una query può convertire il vecchio formato nella struttura prevista dal consumatore attuale. È una forma di compatibilità che evita una modifica massiva immediata, ma aggiunge lavoro alle letture e logica che qualcuno dovrà mantenere.
Esiste anche un’opzione intermedia: mantenere temporaneamente entrambi i formati e migrare gradualmente. Per esempio, l’applicazione può leggere il nuovo formato e, se non è disponibile, convertire quello vecchio; le nuove scritture salvano già il formato aggiornato. Questa strategia richiede regole chiare per evitare che ogni consumatore implementi una propria variante.
Criteri per scegliere
Prima di decidere, descrivete la modifica come un’esigenza osservabile: quali dati cambiano, chi li utilizza e quale comportamento deve essere mantenuto. Poi valutate questi criteri:
- Coerenza: se tutti i consumatori devono vedere lo stesso valore e seguire le stesse regole, una rappresentazione persistente comune può ridurre le discrepanze. Se la conversione è specifica di un’interfaccia o di un consumatore, può essere più adatto un livello di lettura.
- Frequenza e costo delle letture: una trasformazione ripetuta su un percorso molto utilizzato può aumentare la latenza e il consumo di risorse. Se le letture sono poco frequenti o il set di dati è ridotto, il costo potrebbe essere accettabile; misuratelo nel contesto reale.
- Volume e operatività: una migrazione completa può richiedere tempo, controllo degli errori e capacità di elaborare i record senza interrompere il servizio. Per volumi elevati, valutate l’elaborazione in batch e il monitoraggio dell’avanzamento, invece di presumere che una singola operazione sia sicura.
- Numero di consumatori: con più servizi, applicazioni, report o integrazioni, modificare l’archiviazione può avere effetti a catena. Individuate chi dipende dallo schema e se tutti possono essere aggiornati in modo coordinato.
- Reversibilità: trasformare i dati in lettura conserva i dati sorgente e può facilitare il ripristino del comportamento precedente. Una migrazione distruttiva richiede un backup o un meccanismo di ripristino collaudato, oltre a un piano per le modifiche successive.
- Regole di business: se la conversione dipende da decisioni che possono cambiare, conservare i dati originali permette di rivalutarla. Se la nuova forma rappresenta un fatto stabile e necessario a tutti, renderla persistente può semplificare il sistema.
Non confrontate soltanto il costo di eseguire la migrazione con quello di scrivere un adattatore. Considerate anche i costi ricorrenti: query più complesse, osservabilità, test, supporto alle versioni precedenti e futura rimozione della compatibilità.
Quando conviene migrare
Una migrazione persistente diventa spesso più interessante quando il nuovo modello sarà la rappresentazione principale per un periodo lungo, molti consumatori richiedono la stessa trasformazione oppure il lavoro di adattamento incide in modo misurabile sulla latenza. Può essere preferibile anche quando la logica di lettura si è diffusa in più punti e non esiste più un’unica definizione affidabile.
Al contrario, la trasformazione in lettura può essere ragionevole se la modifica è temporanea, il formato precedente deve essere conservato, ci sono pochi consumatori sotto controllo o le regole del nuovo modello sono ancora in fase di convalida. Può essere utile anche quando il costo o il rischio di una scrittura massiva in produzione supera il beneficio immediato, purché le prestazioni siano accettabili e la compatibilità rimanga circoscritta.
Ci sono segnali che indicano che una soluzione temporanea si sta trasformando in debito tecnico: condizioni specifiche per ogni versione storica, query che mescolano formati senza una regola comune, errori diversi tra i consumatori e test che non coprono tutte le varianti. Se emergono, non basta aggiungere un altro caso. Occorre decidere quale formato sarà canonico e stabilire una data o una condizione verificabile per ritirare quelli precedenti.
Come effettuare una transizione graduale
Una migrazione graduale riduce il rischio separando il rilascio dell’applicazione dall’elaborazione di tutti i record. Un piano pratico può seguire questi passaggi:
- Mappare le dipendenze. Individuate produttori, consumatori, processi pianificati, report e contratti di integrazione che utilizzano il modello interessato. Chiarite chi è responsabile di ciascuno.
- Definire la compatibilità. Documentate quali formati sono accettati, quale sia la fonte di verità e cosa debba accadere se manca un campo o compare un valore imprevisto. Evitate deduzioni silenziose che nascondono dati non validi.
- Distribuire lettori compatibili. Assicuratevi che l’applicazione sappia gestire i dati vecchi e nuovi prima di iniziare a scrivere nel nuovo formato. In questo modo si evita che una versione precedente si blocchi incontrando record aggiornati.
- Modificare le scritture. Fate in modo che le nuove operazioni producano il formato previsto. Se per un periodo vengono scritte entrambe le rappresentazioni, definite quale prevale e come rilevare le discrepanze.
- Elaborare i dati esistenti. Eseguite la migrazione in modo controllato, registrando progressi ed errori. Usate batch adatti al sistema e progettate l’operazione affinché possa riprendere senza duplicare gli effetti.
- Ritirare la compatibilità. Eliminate la lettura del vecchio formato solo quando le metriche e le verifiche indicano che non rimangono consumatori o record che ne dipendono.
La sequenza concreta può variare. Nei sistemi con requisiti di disponibilità elevati, le fasi di lettura e scrittura vengono spesso distribuite in modo compatibile prima di modificare i dati. La decisione deve tenere conto del comportamento delle versioni precedenti che potrebbero rimanere attive durante il rilascio.
Convalidare i risultati e preparare il ripristino
Prima di migrare tutto, provate la conversione su dati rappresentativi e confrontate i risultati. Verificate conteggi, campi obbligatori, valori limite, relazioni tra entità e regole di business. Un conteggio identico, da solo, non dimostra che la trasformazione sia corretta: confrontate anche i valori e il comportamento per i casi rilevanti.
Se possibile, eseguite prima un confronto senza modificare il risultato ricevuto dall’utente. Registrate le differenze tra la rappresentazione vecchia e quella nuova, classificate le discrepanze e definite soglie di accettazione prima di estendere il processo. Monitorate errori, latenza e carico durante l’operazione e stabilite chi ha la responsabilità di metterla in pausa.
Il ripristino deve tenere conto delle scritture effettuate dopo la modifica. Ripristinare un backup precedente può eliminare aggiornamenti validi; perciò, stabilite se è possibile tornare al vecchio lettore senza ripristinare i dati o se serve una strategia per riconciliare le modifiche. Provate questo percorso prima di farvi affidamento.
Lista di controllo per decidere
- Il formato canonico e la fonte di verità sono stati identificati?
- Quanti consumatori dipendono dallo schema e chi controlla ciascuno di essi?
- È stato misurato l’impatto della trasformazione in lettura su latenza e risorse?
- La logica temporanea è centralizzata, testata e accompagnata da criteri per la sua rimozione?
- La migrazione può essere messa in pausa, ripresa e usata per individuare i record non riusciti?
- Sono stati definiti confronti, soglie di accettazione e responsabili della convalida dei risultati?
- Esiste un ripristino sicuro che tenga conto delle nuove scritture?
Scegliete la trasformazione in lettura quando la compatibilità è circoscritta, reversibile e gestibile sul piano operativo. Scegliete la migrazione quando il nuovo modello deve essere comune, persistente e più semplice da utilizzare, e c’è un piano sicuro per aggiornare i dati. Se c’è ancora incertezza, adottate una transizione temporanea con metriche, un responsabile e un criterio di uscita: rimandare una migrazione può essere una scelta valida; rimandarla senza una scadenza né controlli rende permanente la compatibilità.