Ciao, e benvenuto nella nona puntata della settantacinquesima stagione. Per otto puntate ti ho raccontato il mondo a eventi, con onestà, costi compresi. Oggi faccio da contrappeso. Non tutto deve essere un evento, non tutto deve essere asincrono, e il mondo a domanda e risposta da cui siamo partiti non è un passato da cui scappare: per un'enorme classe di problemi è la risposta giusta. Lo dico col titolo: non tutto è una notizia.
Partiamo dalla tentazione, che dopo otto puntate è forte. Quando impari a usare un martello, tutto comincia a sembrarti un chiodo: hai imparato gli eventi, e adesso vorresti trasformare ogni cosa in un evento, ogni chiamata in un messaggio. Quell'istinto è il modo in cui una buona architettura si rovina. La bravura non è usare gli eventi: è sapere quando non usarli.
Allora lasciami difendere con convinzione l'altra parte, la domanda e risposta. Quando fai una domanda e ti serve la risposta adesso, è semplicemente giusta. "Qual è il saldo di questo utente?" "Questa password è corretta?" Vuoi la risposta subito, in un posto solo, e vuoi sapere se è andata male. Le chiamate sincrone sono semplici da scrivere, da leggere, da debuggare: l'intero flusso sta in un'unica traccia. La consistenza immediata e forte è il punto di partenza, non qualcosa che devi costruirti. Per tantissimo software, una ricerca, un modulo, un accesso, non è solo accettabile, è meglio. Non farne una notizia: fai la domanda e basta. Sono le vecchie interfacce a domanda e risposta, e non sono il nemico.
C'è anche una spia grammaticale, e torna la pietra angolare. Il comando è la forma naturale della domanda e risposta. "Addebita questa carta" e aspetti di vedere se ha funzionato: quello è un comando, e travestirlo da evento, "addebito richiesto", nasconde solo che ti serve una risposta. Se devi conoscere l'esito prima di proseguire, vuoi una chiamata, non un annuncio. Forzarlo in un evento ti costa la risposta che ti serve.
Detto questo, sono altrettanto convinto di quando gli eventi se lo guadagnano. Brillano dove vale il contrario: dove non ti serve una risposta immediata, dove tante parti si interessano allo stesso fatto, dove i pezzi devono evolvere per conto loro, dove la storia conta, dove integri sistemi che è giusto non si conoscano. Disaccoppiamento, scala, verificabilità, integrazione: il loro terreno di casa. Quando il fatto interessa a persone che non sai nominare, allora sì che è una notizia: pubblicala.
Mettiamo giù la decisione, ed è il filo che attraversa tante nostre stagioni. Due domande. Una: mi serve la risposta adesso, per continuare? Se sì, pendi verso domanda e risposta. Due: a questo fatto si interessa più di una parte che non conosco, adesso o in futuro? Se sì, pendi verso l'evento. Quasi tutti i sistemi veri sono una miscela: sincroni dove ti serve una risposta, asincroni dove devi dirlo al mondo. La qualità sta nel tracciare bene quella linea, non nello scegliere una fazione. Un sistema tutto sincrono non scala; uno tutto a eventi non risponde a una domanda semplice senza una catena infinita.
Chiamiamo per nome i due errori opposti, perché ci cadiamo tutti. Il primo è il monolite distribuito: hai spezzato tutto in servizi e li hai ricuciti con così tante chiamate sincrone da avere tutta la complessità della distribuzione e niente del disaccoppiamento. Il secondo è lo specchio: gli spaghetti di eventi, dove ogni cosa è un evento, nessuno segue cosa causa cosa, e un banale "qual è il saldo" richiede di ripercorrere la storia. Nascono entrambi dallo stesso gesto: un'idea sola dappertutto, invece di scegliere problema per problema.
E qui la metafora chiude il cerchio, un'ultima volta prima del finale. Un giornale non pubblica tutto: una telefonata privata tra redattori non è una notizia, un contratto in un cassetto non è una notizia, una domanda risolta in corridoio non è una notizia. Il giornale pubblica ciò che il pubblico ha davvero bisogno di sapere, i fatti che contano per persone che non incontrerà mai. L'arte della redazione non è stampare di più: è il giudizio su cosa merita di salire al rango di notizia. La tua architettura ha bisogno dello stesso giudizio.
E così si chiude, onestamente, l'argomento magia e macchina. La magia diceva: disaccoppia tutto con gli eventi. La macchina risponde: gli eventi sono uno strumento con un costo, che vale la pena solo dove disaccoppiamento, scala, storia o integrazione ti ripagano. Usarli dappertutto non è raffinatezza: è lo stesso errore che usarli da nessuna parte, ribaltato.
Voglio lasciarti con questo. L'obiettivo non è mai stato trasformare tutto il sistema in un flusso di eventi, ma darti un secondo modo di collegare le cose, l'annuncio accanto alla domanda, e il giudizio per capire quale dei due ti sta chiedendo un certo problema. Tieni la chiamata sincrona dove ti serve una risposta, prendi l'evento dove devi dirlo al mondo. Non tutto è una notizia, e chi conosce la differenza costruisce sistemi più calmi.
Per oggi ci fermiamo qui. Ho difeso la domanda e risposta, giusta quando ti serve una risposta adesso, e ricordato dove invece gli eventi si guadagnano il posto. Ho dato un criterio a due domande, e ho chiamato per nome i due errori opposti: il monolite distribuito e gli spaghetti di eventi. Il punto è far combaciare lo strumento con il problema, invece di innamorarsi di uno strumento. Nella prossima e ultima puntata: raccontare, non comandare. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.