Cos'è l'event sourcing?

L'event sourcing è il pattern che registra ogni cambiamento allo stato di un'applicazione come una sequenza di eventi, invece di salvare soltanto l'ultimo valore. L'idea è antica quanto i registri contabili, e la descrizione di riferimento per il software è quella di Martin Fowler, del 12 dicembre 2005. Un ordine, in un sistema tradizionale, è una riga che viene sovrascritta: cambia stato, cambia indirizzo di consegna, e la storia di come ci si è arrivati sparisce a ogni scrittura successiva, sostituita dall'ultimo valore. Con l'event sourcing quella riga non esiste: esiste un log di eventi immutabili e ordinati (creato, pagato, spedito, reso) e lo stato attuale si ottiene rileggendo il log dall'inizio, un evento alla volta, invece che leggendolo già pronto da una tabella. Il log è la fonte di verità, lo stato che l'applicazione mostra è una sua conseguenza calcolata al momento della lettura, non un fatto salvato altrove e quindi soggetto a scostarsi da esso col tempo.

Leggi anche: CQRS · Separare il modello che scrive i dati da quello che li legge, invece di usarne uno solo per entrambi i compiti.

Cosa guadagna chi lo adotta, e cosa costa

Fowler elenca tre capacità che derivano dal log. La ricostruzione completa: da un sistema vuoto si rigenera lo stato attuale semplicemente rieseguendo tutti gli eventi. L'interrogazione temporale: ogni evento porta il proprio momento, quindi si può chiedere quale fosse lo stato in un istante qualunque del passato. E il replay corretto: un evento elaborato con logica sbagliata si annulla e la sequenza si rigioca con la logica giusta, invece di correggere a mano un dato ormai inconsistente. Il costo è duplice. Da un lato, un sistema che invia email o effettua pagamenti non distingue un replay da un'esecuzione vera, quindi va isolato dal log; e introdurre l'event sourcing su un sistema esistente è "molto difficile", avverte Fowler, perché la storia pregressa non è mai stata catturata come eventi. Dall'altro, il formato degli eventi va evoluto per anni senza perdere la leggibilità di quelli vecchi (vedi evoluzione dello schema), e chi vuole conoscere lo stato corrente senza rigiocare l'intero log ha bisogno di una proiezione: una vista già calcolata e tenuta aggiornata, che è esattamente il compito che il CQRS assegna al lato lettura. I due pattern si adottano spesso insieme ma restano distinti: si può avere CQRS senza event sourcing, con il lato scrittura su un database relazionale ordinario.

Un esempio enterprise

Un magazzino industriale italiano gestisce ordini e giacenze su un gestionale che aggiorna la quantità disponibile a ogni movimento. Un cliente contesta un saldo, sostenendo di aver reso dieci pezzi mai accreditati. Con un saldo che viene sovrascritto, ricostruire cosa è successo richiede di incrociare email, bolle e la memoria di chi ha lavorato l'ordine. Con un log di eventi (ricevuto, prelevato, spedito, reso, storno) la sequenza esatta è già lì, con data e operatore su ciascun passaggio, e il saldo di ieri si ottiene fermando il replay al momento giusto invece di affidarsi a un backup notturno.

Perché conta per chi decide

Il costo dell'event sourcing si ripaga dove la tracciabilità è un requisito: contabilità, saldi creditizi, fatturazione, ovunque un revisore o un cliente possa chiedere "come si è arrivati a questo numero" e la risposta debba esistere. È over-engineering quasi ovunque altrove: su un CRUD gestito da un piccolo team senza obbligo di audit, il log aggiunge una proiezione da mantenere e un formato da far evolvere per anni, a fronte di un beneficio che nessuno ha chiesto. La domanda utile prima di adottarlo è se qualcuno dovrà davvero ricostruire il passato o correggerlo con una logica diversa da quella con cui è stato scritto la prima volta.