Ciao, e benvenuto nella quinta puntata della settantacinquesima stagione. Per quattro puntate ho parlato dei vantaggi veri dell'architettura a eventi. Oggi arriva il conto. Non per spaventarti, ma per farti pagare a occhi aperti: ogni vantaggio ha un prezzo, e oggi quel prezzo lo metto sul tavolo, pezzo per pezzo. È la puntata più onesta della stagione.
Onoriamo un'ultima volta i vantaggi. Il disaccoppiamento è reale, le squadre indipendenti sono reali, la resistenza nel tempo e il riuso di un fatto per mille scopi sono reali, e li hai guadagnati sul serio. Adesso il conto.
Primo costo, il più profondo e il meno intuitivo: la consistenza eventuale. Nel mondo delle telefonate, quando un servizio ti risponde, in quell'istante siete d'accordo su com'è fatto il mondo. Nel mondo degli eventi i fatti viaggiano e arrivano in momenti diversi, e così, per un po', pezzi diversi del sistema credono cose diverse. L'ordine esiste nel servizio ordini, ma il magazzino non lo sa ancora; il cliente vede "confermato", ma la fatturazione pensa che non sia successo niente. Nessuno sta sbagliando: sono in punti diversi della stessa storia. È la mattina in cui esce una notizia grossa: chi ha letto il giornale e chi non l'ha aperto non sono d'accordo su com'è il mondo, e per un po' hanno ragione tutti e due. Il tuo sistema vive dentro quella fessura, in continuazione, e devi progettarlo per il "vero, ma non ancora dappertutto".
Secondo costo, il flusso che non vedi. Quando qualcosa va storto, non c'è un'unica traccia d'errore da leggere dall'alto in basso. L'ordine è stato effettuato, e poi? Chi ha reagito? Il magazzino ha sentito? La mail è partita? Il comportamento è sparso tra i servizi e nel tempo, e nessun file racconta la storia intera. Il debug diventa archeologia: ricostruisci dai reperti quello che il codice non mostra più. Per questo, a eventi, vedere il flusso smette di essere un lusso: se non te la costruisci apposta, quella capacità il codice non te la regala. Qui torna quello che ci siamo detti su osservabilità e tracciamento.
Terzo costo: l'ordine di arrivo. I fatti possono arrivare in disordine. "Ordine annullato" può raggiungere un lettore prima di "ordine effettuato", e ora quel lettore ha un annullamento per un ordine di cui non ha mai sentito parlare. Nelle telefonate l'ordine era implicito, chiamavi in sequenza; negli eventi devi pensarci apposta: questi fatti devono arrivare in ordine, e cosa succede se non lo fanno? Sul giornale è una rettifica stampata prima dell'articolo che corregge.
Quarto costo: la consegna doppia. Lo stesso fatto può arrivare due volte, perché il sistema di consegna, pur di non perdere niente, nel dubbio preferisce rimandartelo se non è sicuro che l'hai ricevuto. Così lo stesso "pagamento ricevuto" atterra due volte, e se il tuo lettore reagisce ingenuamente due volte, hai addebitato il cliente due volte o spedito due pacchi. Sono due agenzie che riportano lo stesso avvenimento, e una redazione distratta lo stampa come due notizie. Devi rendere i tuoi lettori capaci di vedere lo stesso fatto due volte e reagire una sola. A questo dedicheremo spazio più avanti.
Quinto costo, quello che riassume tutti: il peso operativo. L'edicola, il monitoraggio, i recuperi, i contratti dei fatti sono un sistema che adesso devi far girare. Le telefonate avevano meno macchineria, perché il flusso viveva nel codice. Hai spostato la complessità dal codice alle operazioni: non è scomparsa, ha cambiato forma, da qualcosa che leggevi a qualcosa che devi far funzionare.
E c'è il momento più onesto di tutti, quello che ogni squadra a eventi ha vissuto alle due di notte. Un fatto è stato pubblicato, qualcosa doveva succedere, e non è successo. E tu fissi un sistema senza errori: niente è andato in crash, niente ha registrato un guasto, perché il fatto è caduto in una fessura tra due servizi. Il silenzio è la parte più dura. Una telefonata che fallisce, fallisce ad alta voce; un evento perso si perde in silenzio.
Voglio essere chiaro: non è una condanna, è un conto. Nessuno di questi costi rende l'architettura a eventi sbagliata, e ognuno è gestibile: le prossime puntate ti danno gli attrezzi. Il punto è un altro: non sono casi limite, sono il clima normale di un sistema asincrono. Se qualcuno ti vende gli eventi senza nominarti questo clima, ti sta vendendo la magia e nascondendo la macchina. Il mondo asincrono ti chiede di rinunciare a una comodità che non sapevi di avere: una verità unica, al presente, condivisa da tutti e leggibile in un posto solo. In cambio ti dà portata, resistenza e scala. Per tanti sistemi è un buon affare, ma solo se il conto lo paghi davvero. Le squadre che soffrono di più sono quelle che hanno preso i vantaggi a credito.
Per oggi ci fermiamo qui. Ho messo sul tavolo cinque costi: la consistenza eventuale, parti del sistema che per un po' credono cose diverse; il flusso che non vedi, che rende il debug un'archeologia; l'ordine di arrivo, non più garantito; la consegna doppia, che ti costringe a reagire una volta sola a fatti ripetuti; e il peso operativo, la complessità spostata dal codice alle operazioni. E ho descritto il costo che li riassume: l'evento perso che si perde in silenzio. Non è una condanna, è il prezzo da conoscere prima di comprare. Nella prossima puntata: l'archivio dei fatti. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.