Il pericolo delle integrazioni che falliscono in silenzio
Quando due sistemi aziendali si parlano — un gestionale che invia le ore lavorate a un software di contabilità, un ERP che sincronizza le anagrafiche con un CRM — c’è un’operazione che si ripete migliaia di volte al giorno e che quasi nessuno guarda: la risoluzione di un riferimento. Il sistema A ha un codice, un nome, una sigla; deve trovare a cosa corrisponde nel sistema B. Sembra banale. È il punto in cui le integrazioni si rompono più silenziosamente.
Due fallimenti che sembrano uno solo
Immaginiamo di dover associare ogni movimento a una “dimensione contabile” — un centro di costo, una commessa, una classe. Il codice cerca la corrispondenza nel sistema esterno. La ricerca può andare male in due modi profondamente diversi:
- Il dato non esiste davvero. La corrispondenza non c’è: nessuno l’ha mai creata.
- La ricerca è fallita per un motivo transitorio. Un timeout, una risposta lenta, un token scaduto per un istante. Il dato esiste, ma in quel momento non l’abbiamo trovato.
Dal punto di vista del codice ingenuo, entrambi i casi restituiscono la stessa cosa: “non trovato”. Ed è qui che nasce il danno.
Il fallback che indovina
La tentazione, davanti a un “non trovato”, è cavarsela con un ripiego: se non trovo la corrispondenza esatta, uso quella più simile. Se non trovo la classe con il nome completo, provo con il nome breve. L’integrazione non si blocca, il movimento passa, tutti contenti.
Solo che se il “non trovato” era in realtà un errore transitorio, abbiamo appena scritto un dato sbagliato in un sistema contabile — con la comoda apparenza di aver funzionato. E il secondo tranello è ancora più insidioso: se quel fallimento temporaneo viene messo in cache, un singolo timeout avvelena tutte le operazioni successive. Un errore di un millisecondo diventa un errore di giornata.
Fail-closed: fermarsi è più economico che indovinare
La lezione, imparata sul campo, è controintuitiva per chi ottimizza la fluidità: quando un riferimento critico non si risolve con certezza, l’integrazione deve fermarsi, non arrangiarsi. Bloccare il movimento e segnalarlo è fastidioso; scrivere il dato giusto nel posto sbagliato è un problema che scopri tre mesi dopo, in fase di chiusura contabile, senza sapere da dove venga.
Tre principi che ne derivano:
- Distinguere sempre “non esiste” da “non ho potuto verificare”. Sono errori di natura diversa e vanno trattati in modo diverso.
- Non mettere mai in cache un fallimento transitorio. Si ricorda ciò che è certo, non ciò che è andato storto una volta.
- Sui dati critici, meglio bloccare che degradare. Un’eccezione visibile costa un intervento; un dato corrotto in silenzio costa un’indagine.
Le integrazioni non si giudicano da quanto sono fluide quando tutto va bene, ma da come si comportano nell’istante in cui qualcosa va storto. Un’integrazione seria, in quel momento, ha il coraggio di dire “mi fermo” invece di indovinare.