Event sourcing nella pratica: lezioni da sistemi in produzione

Perché attrae

L'event sourcing registra ogni cambio di stato come un evento immutabile. Invece di sovrascrivere lo stato corrente, aggiungi in coda ciò che è successo. Ottieni così un audit trail completo, la possibilità di ricostruire lo stato in qualsiasi momento e una corrispondenza naturale con le architetture event-driven. Nei settori regolati, dove l'auditabilità è un obbligo di legge, il vantaggio è evidente.

Dove le implementazioni fanno fatica

Dopo aver portato l'event sourcing in sistemi in produzione tra servizi finanziari, logistica e integrazione enterprise, lo schema che emerge è sempre lo stesso: l'event store è la parte facile. La complessità sta in tutto ciò che gli gira intorno.

Gestione delle proiezioni

I read model (le proiezioni) vanno ricostruiti dallo stream di eventi ogni volta che cambia il loro schema. Per una proiezione su milioni di eventi non è un'operazione istantanea. Serve una strategia: switch blue-green tra proiezioni, ricostruzione in background con monitoraggio dell'avanzamento e ritorno alla versione precedente se quella nuova non supera la validazione. La maggior parte dei team sottovaluta questo carico operativo.

Evoluzione dello schema

Gli eventi sono immutabili, il loro schema no. Quando cambiano i requisiti di business devi introdurre nuovi tipi di evento mantenendo la retrocompatibilità con quelli esistenti. L'upcasting (trasformare i vecchi eventi nel nuovo schema al momento della lettura) funziona ma aggiunge complessità. I tipi di evento versionati con logica di migrazione esplicita sono l'approccio che scala, ma richiedono disciplina fin dal primo giorno.

Strategia degli snapshot

Ricostruire un aggregato da migliaia di eventi a ogni lettura non è praticabile. Servono gli snapshot, cioè materializzazioni periodiche dello stato dell'aggregato. Le decisioni da prendere: frequenza degli snapshot, dove salvarli (nello stesso store o in uno separato), strategia di invalidazione quando cambiano le proiezioni e il problema dell'avvio a freddo per gli aggregati che non sono mai stati fotografati.

Event sourcing e audit trail dell'AI

Nei nostri deployment AI l'event sourcing ha portato un vantaggio inatteso: offre un'architettura naturale per gli audit trail dell'AI. Quando un sistema AI elabora una richiesta, l'intera interazione (l'input, il contesto recuperato, il modello invocato, l'output grezzo, l'output validato e ogni azione di revisione umana) può essere modellata come una sequenza di eventi immutabili.

Non è teoria. In Nexus MDS Core il livello di governance degli output usa un audit log basato su event sourcing. Ogni interazione con l'AI viene salvata come una catena di eventi: QueryReceived → ContextRetrieved → InferenceCompleted → ValidationPassed → ResponseDelivered (oppure ValidationFailed → HumanReviewRequested → HumanApproved → ResponseDelivered). Questo dà alle autorità di vigilanza, e all'organizzazione stessa, la possibilità di ricostruire da zero qualsiasi decisione assistita dall'AI, in qualsiasi momento.

Il requisito di "tracciabilità" che l'AI Act pone ai sistemi AI ad alto rischio corrisponde direttamente alla garanzia centrale dell'event sourcing: nulla si perde, nulla viene sovrascritto e la storia completa è sempre disponibile. Le organizzazioni che hanno già adottato l'event sourcing per i processi di business principali partono con un vantaggio strutturale quando devono portare in produzione sistemi AI progettati su questi requisiti.

Scelte tecnologiche: EventStoreDB, Kafka o soluzione su misura

La scelta della tecnologia per l'event store è una delle prime decisioni, e una delle più importanti. Dai nostri deployment in produzione:

• EventStoreDB: nato per l'event sourcing. Supporto nativo per uno stream per aggregato, proiezioni e subscription. Ottimo per progetti greenfield in cui il team sceglie l'event sourcing come modello dati principale. Il carico operativo è moderato: è un database specializzato che richiede competenze specifiche.
• Apache Kafka: non è progettato per l'event sourcing, ma è molto usato in questo ruolo. Funziona bene quando l'event sourcing è parte di un'architettura event-driven più ampia e il team gestisce già Kafka. Il compromesso: Kafka non offre un modo nativo ed efficiente per leggere lo stream di eventi di un singolo aggregato, quindi di solito serve un indice secondario o uno store separato per idratare gli aggregati.
• PostgreSQL con tabelle append-only: la scelta pragmatica quando il team è già forte su PostgreSQL e il volume di eventi è moderato. Perdi le funzioni specializzate (proiezioni native, catch-up subscription) ma guadagni semplicità operativa e puoi usare strumenti che conosci già per debug e monitoraggio.

La nostra raccomandazione: se l'event sourcing è il pattern architetturale centrale e il team ha le competenze, usa EventStoreDB. Se l'event sourcing è un componente di un sistema event-driven più grande, usa Kafka con un livello di proiezione costruito ad hoc. Se il team è piccolo e il pragmatismo conta più della purezza, PostgreSQL con tabelle append-only ben progettate ti dà gran parte del beneficio con una frazione del costo operativo.

Quando usarlo

L'event sourcing è la scelta giusta quando l'auditabilità è un requisito vincolante, quando ti servono interrogazioni temporali ("qual era lo stato al momento T?") o quando il tuo dominio è per natura event-driven (gestione ordini, transazioni finanziarie, tracciamento logistico). È la scelta sbagliata quando ti basta un CRUD con un audit log: una semplice tabella di audit append-only raggiunge lo stesso obiettivo con una frazione della complessità operativa.

Gli anti-pattern che abbiamo osservato: usare l'event sourcing per entità CRUD semplici che cambiano di rado (profili utente, configurazione), applicarlo a carichi dominati dalla lettura dove pesa soprattutto il costo di idratazione degli aggregati (cataloghi, dati di riferimento) e adottarlo senza investire negli strumenti di gestione delle proiezioni (il che porta inevitabilmente a script manuali sul database che vanificano lo scopo del pattern).

Per le organizzazioni dei settori regolati, dove l'auditabilità non è negoziabile e le interrogazioni temporali sono uno strumento di compliance, l'event sourcing non è solo un pattern tecnico. È un investimento architetturale nella preparazione normativa. Per capire come applichiamo i pattern event-driven nelle integrazioni enterprise, guarda il nostro servizio di integrazione enterprise.