Shadow e Dual Run: verificare il nuovo sistema prima del cutover
Shadow e Dual Run riducono il rischio di migrazione confrontando il nuovo comportamento con quello legacy prima di renderlo source of truth.
Shadow Mode
In Shadow Mode il sistema nuovo riceve una copia delle richieste o degli eventi, esegue il proprio comportamento e produce un risultato osservabile, ma non determina l'esito operativo. Il legacy resta autoritativo. È una modalità ideale per validare matching, calcoli, mapping e read model senza impatto clinico.
Dual Run
Nel Dual Run entrambi i percorsi sono attivi e il confronto diventa parte esplicita del processo di migrazione. A seconda del caso, uno solo può scrivere il dato autoritativo oppure entrambi possono produrre output controllati destinati a riconciliazione. La regola di authority deve essere inequivocabile.
Cosa confrontare
Identificativi e correlazioni tra paziente/episodio/ordine.
Stati finali e transizioni di workflow.
Payload di integrazione normalizzati, ignorando campi tecnici non deterministici.
Tempi di risposta, timeout e percentuali di errore.
Copertura funzionale e casi non riconosciuti.
Differenze semantiche classificate: bug nuovo, anomalia legacy o regola non documentata.
Non basta duplicare il traffico
Un vero shadow test ha un comparatore. Se il nuovo sistema gira in parallelo ma nessuno misura le divergenze, si ottiene solo costo aggiuntivo. Servono metriche, dataset di riferimento, soglie e un processo di triage.
Stati di migrazione utili
LEGACY: solo il vecchio è autoritativo.
SHADOW: il nuovo osserva/esegue senza effetto operativo.
DUAL-RUN: entrambi partecipano con confronto sistematico.
AUTHORITATIVE: il nuovo diventa source of truth e il legacy è fallback o read-only.
RETIRED: il percorso legacy e il relativo ACL possono essere rimossi.
Attenzione ai side effect
Non si può duplicare alla cieca un comando che invia prescrizioni, produce notifiche, apre pratiche o modifica sistemi esterni. In Shadow Mode gli adapter di side effect devono essere sostituiti da sink, simulatori o registratori controllati.
Criterio di cutover
Il passaggio ad AUTHORITATIVE deve dipendere da evidenze: volume sufficiente, divergenze comprese, soglie di errore, runbook di rollback e ownership operativa. La sensazione che «sembra funzionare» non è un gate.