Event Sourcing e CQRS Pattern: come funzionano

Con l’evoluzione dei moderni sistemi software, cresce anche il numero di task sempre più complesse da dover gestire, e diventa più importante il ruolo che questi sistemi assumono nella società. Aumentano di conseguenza la responsabilità, la complessità e la richiesta di affidabilità, scalabilità e sicurezza.

I sistemi software devono rispettare normative di conformità più severe, soprattutto in settori come i servizi finanziari, in cui è fondamentale avere registri accurati e garantire la tracciabilità dei dati.

Immaginate una piattaforma di servizi finanziari che gestisce le transazioni degli utenti e i saldi dei conti. Il sistema deve poter offrire prestazioni elevate e al contempo preservare un audit log dettagliato per la tracciabilità. Ad esempio, se un cliente contesta una transazione, la piattaforma dovrebbe essere in grado di ricostruire l’esatta sequenza di azioni che hanno portato allo stato attuale del conto. Affidarsi esclusivamente alle tradizionali operazioni CRUD (Create, Read, Update, Delete) può complicare questo processo, poiché ogni aggiornamento sovrascrive i dati precedenti, lasciando poche informazioni passate.

Per superare queste sfide, lo sviluppo software moderno si rivolge a potenti modelli architetturali come Event Sourcing e Command Query Responsibility Segregation (CQRS), noto anche come CQRS Pattern. Questo articolo esplorerà il modo in cui questi modelli possono migliorare l’affidabilità del sistema, la scalabilità, la coerenza dei dati e la tracciabilità. Cercheremo poi di evidenziare come questi pattern migliorano la gestione degli eventi in sistemi complessi, garantendo che ogni azione venga registrata e sia facilmente accessibile.

Event Sourcing e CQRS

Prima di addentrarci nell’articolo, faremo una piccola comparazione tra Event Sourcing e CQRS analizzando alcuni fattori come definizione, concetto fondamentale, casi d’uso, vantaggi e svantaggi.

Cos’è Event Sourcing? 

Event Sourcing è un pattern architetturale che tiene traccia delle modifiche in un dominio registrandole come eventi di dominio immutabili in una memoria di eventi (event store) di sola aggiunta (append-only). Invece di archiviare semplicemente lo stato più recente in un archivio di dati, questo approccio conserva ogni modifica come una sequenza di eventi. Riproducendo tutti gli eventi in ordine, è possibile ricostruire lo stato dell’applicazione o dell’oggetto di dominio in qualsiasi momento.

Ciò che rende questo metodo particolarmente potente è la profondità delle informazioni che fornisce. Invece di vedere solo lo stato corrente della vostra applicazione, l’event store può darvi accesso all’intero percorso di decisioni, azioni e modifiche che l’hanno costruita. Questa cronologia completa diventa importantissima per il debug, l’audit e la comprensione di logiche e comportamenti aziendali complessi.

A differenza del tradizionale modello di persistenza dei dati, che archivia solo lo stato più recente e sovrascrive i dati precedenti con i vari aggiornamenti, Event Sourcing cattura ogni modifica, conservando una cronologia completa degli eventi. 

Ad esempio, immaginiamo un’app di online banking in cui gli utenti trasferiscono dei fondi:

• Nel tradizionale sistema basato sullo stato:
  • Se Alice ha $500 e invia $100 a Bob, il sistema aggiorna il suo saldo da $500 a $400. Il vecchio saldo viene sovrascritto, e perderemo così i dettagli sulle modalità di cambiamento del saldo.
• In un sistema basato sugli eventi:
  • Anziché aggiornare direttamente il saldo, il sistema registra un evento del tipo Alice ha trasferito $100 a Bob.
  • In seguito, se Alice contesta la transazione o è necessario controllare il suo account, è possibile riprodurre tutta la serie di eventi registrati (ad esempio, ha depositato $500, ha trasferito $100) per ricostruire la linea del suo saldo in qualsiasi momento.

Questo approccio, che consiste nel catturare ogni azione come evento immutabile, pone le basi per i principi fondamentali che definiscono il modo in cui opera Event Sourcing.

Principi fondamentali di Event Sourcing

Lo schema Event Sourcing funziona bene grazie ad alcuni principi fondamentali:

Eventi: Registrazioni immutabili che catturano ogni cambiamento nello stato del sistema. Ogni evento rappresenta un’azione o un avvenimento specifico e distinguibile. Per esempio, in un sistema e-commerce, alcuni eventi comuni potrebbero essere OrderPlaced, PaymentProcessed, and OrderShipped.

• Stream: Uno stream è un flusso, una sequenza ordinata di eventi legata a un’entità o a un processo particolare. Continuiamo con l’esempio dell’e-commerce; in questo caso un singolo stream dell’ordine di un cliente apparirebbe più o meno così:

• Proiezioni: Le proiezioni sono modelli di lettura costruiti a partire dai dati degli eventi. Trasformano quindi dei normali eventi in dati significativi che le applicazioni possono efficientemente interrogare. Ad esempio, le proiezioni possono tracciare le entrate totali, il numero di ordini per cliente, e i livelli di stock dell’inventario.

Vantaggi di Event Sourcing

Event Sourcing offre molti benefici che la rendono una efficace scelta di design:

• Audit trail completa (tracciabilità): ogni cambiamento di stato è registrato come evento, dando un registro storicamente completo di cosa è successo e quando. Questo semplifica notevolmente il debug, l’analisi forense, e gli audit di conformità.
• Recupero e riproduzione dei dati: riproducendo gli eventi dal registro eventi, è possibile ricostruire lo stato del sistema in qualsiasi momento. Questo è importante per il ripristino di sistema (disaster recovery), il ripristino di dati danneggiati o per investigare su problemi passati.
• Proiezioni flessibili: le proiezioni consentono di creare modelli di lettura personalizzati, cuciti addosso a specifiche esigenze aziendali. Ciò consente query ottimizzate senza alterare i dati originali.
• Scalabilità migliorata: i flussi di eventi sono ideali per la scalabilità orizzontale. I sistemi possono consumare ed elaborare gli eventi in modo asincrono, aumentando le prestazioni in ambienti distribuiti.

A questo punto potrebbe non essere immediatamente ovvio, ma Event Sourcing separa intrinsecamente le azioni di scrittura (eventi) dalle azioni di lettura (proiezioni). Questa separazione è una delle ragioni principali per cui si parla spesso di CQRS insieme a Event Sourcing, poiché CQRS perfeziona ulteriormente questa separazione in componenti architetturali distinti.

Cos’è CQRS? 

Command Query Responsibility Segregation (CQRS) è un pattern architetturale che separa le operazioni di lettura e scrittura di un sistema. In altre parole, promuove la progettazione di percorsi distinti per la gestione dei command (che modificano i dati) e delle query (per il recupero dei dati).

Un principio fondamentale alla base di CQRS è che un metodo dovrebbe leggere o scrivere dati, mai entrambe le cose. Inoltre, le query non dovrebbero mai modificare lo stato del sistema; dovrebbero solo restituire informazioni. Ciò garantisce che le operazioni di lettura non abbiano effetti collaterali sui dati e che siano ottimizzate esclusivamente per il recupero dei dati.

Perché separare command e query?

Dividere command e query offre diversi vantaggi pratici:

• Migliore chiarezza e manutenibilità del codice: se ogni metodo si dedica alla scrittura o alla lettura dei dati, la base di codice diventa più pulita e facile da gestire.
• Scalabilità incrementata: Poiché le operazioni di lettura spesso prevalgono su quelle di scrittura, CQRS permette di scalare il modello di lettura indipendemente dal modello di scrittura per query più prestazionali. 

Maggiore flessibilità per sistemi complessi: CQRS si adatta naturalmente alle architetture basate sugli eventi, in cui i command generano eventi e le query consumano le proiezioni. Questa separazione semplifica l’aggiunta di nuove funzionalità, come l’analisi o il reporting, senza modificare complesse logiche di business.

In che modo Event Sourcing e CQRS cooperano: 

Nonostante i suoi vantaggi, Event Sourcing introduce una sfida significativa: maggiore complessità. Scrivere dati in un sistema event-sourced sembra semplice: l’applicazione crea semplicemente un evento e lo aggiunge a un registro eventi. Tuttavia, il recupero dei dati è qualcosa di molto più complesso.

Per recuperare lo stato attuale dei dati in un dato momento, il sistema deve aggregare tutti gli eventi rilevanti fino a quel momento. Questo processo può essere lento e imprevedibile, rendendo le richieste di lettura significativamente meno efficienti di quelle di scrittura. Gestire entrambe le operazioni all’interno dello stesso modello di dati può portare a serie complicazioni.

La causa di queste complicazioni risiede nelle diverse esigenze tra le operazioni di lettura e scrittura. Inoltre, molti sistemi sperimentano un chiaro squilibrio tra le operazioni di lettura e scrittura. Ad esempio, le applicazioni rivolte all’utente in genere sono caratterizzate da molte più letture che scritture, poiché gli utenti consumano principalmente i dati anziché modificarli. Al contrario, alcuni sistemi, come il back office di una banca o una piattaforma di tracciamento dei veicoli, possono sperimentare enormi carichi di scrittura e poche richieste di lettura.

L’ottimizzazione dei modelli di dati per le letture può comportare l’aggiunta di indici, che possono rallentare le scritture e viceversa. È qui che CQRS si dimostra fondamentale. Separando i modelli di lettura e scrittura, CQRS riduce la complessità e consente a ciascun modello di scalare in modo indipendente in base alle sue esigenze specifiche.

La combinazione di Event Sourcing e CQRS offre diversi vantaggi aggiuntivi:

• Tracciamento delle modifiche: poiché ogni modifica di stato viene registrata come un evento, si può ottenere una cronologia dettagliata che mostra cosa è successo, quando e perché. Questi stessi dettagli dell’evento semplificano il monitoraggio dell’evoluzione dei dati.
• Audit dei dati: un registro eventi completo fornisce ovviamente una solida audit trail, fondamentale per la responsabilità, la conformità e le indagini forensi.
• Riduzione delle controversie: isolando i modelli di lettura e scrittura, CQRS riduce al minimo i colli di bottiglia. Le letture possono sfruttare dati denormalizzati ottimizzati per ricerche rapide, mentre le scritture si concentrano sul mantenimento dell’integrità transazionale.
• Miglioramento della sicurezza: con modelli di lettura e scrittura distinti, è possibile applicare controlli più rigorosi sulle operazioni di scrittura, garantendo al contempo che i dati di lettura siano ampiamente accessibili senza comprometterne l’integrità.

Riassumendo: quando si verifica un evento, questo può attivare aggiornamenti a uno o più modelli di lettura ottimizzati per le query. In questo modo, la parte di scrittura può concentrarsi sulla cattura della cronologia, mentre la parte di lettura può fornire visualizzazioni ottimizzate e personalizzate dei dati per query efficienti, che è proprio una comune applicazione delle reads in un’architettura CQRS. Queste Single View unificate sono in genere proiezioni create da modifiche dei dati sottostanti.

Fast Data di Mia-Platform migliora significativamente Event Sourcing e CQRS attraverso il suo modello asincrono. Sfruttando un approccio basato su flussi Kafka, Fast Data acquisisce ed elabora in modo efficiente eventi immutabili.

Questi flussi di eventi vengono quindi utilizzati in modo asincrono per materializzare modelli di lettura ottimizzati (Single Views), allineandosi perfettamente con il lato query di CQRS. Questa elaborazione asincrona garantisce che le operazioni di scrittura (Event Sourcing) e le operazioni di lettura (CQRS tramite Single Views) siano disaccoppiate, migliorando la reattività e la scalabilità.

Il Fast Data Control Plane semplifica ulteriormente la gestione di queste pipeline di dati asincrone, riducendo la complessità spesso associata all’implementazione di Event Sourcing e CQRS.

Ricapitolando

I tradizionali metodi di persistenza dei dati basati sullo stato stanno diventando sempre meno efficaci nel soddisfare le esigenze delle applicazioni moderne. Man mano che i sistemi diventano più complessi, la necessità di una migliore scalabilità, tracciabilità e di maggiori prestazioni diventa cruciale. Per affrontare queste sfide, le aziende sono più invogliate ad adottare modelli come Event Sourcing e CQRS.

Questi pattern forniscono una base solida su cui costruire sistemi scalabili, sicuri, e affidabili. I più grandi vantaggi sono riscontrabili in settori quali finanza, assistenza sanitaria e analisi in tempo reale, dove un’archiviazione accurata e una gestione flessibile dei dati sono fondamentali.

However, implementing Event Sourcing and CQRS can be challenging, especially when compared to traditional state-based approaches. This is where solutions like Mia-Platform Fast Data become essential.

Comunque, l’implementazione di Event Sourcing e CQRS può comportare diverse sfide, specialmente se pensiamo ai tradizionali approcci state-based. Fast Data di Mia-Platform può rappresentare una soluzione importante per affrontare queste sfide.

Fast Data semplifica lo sviluppo di applicazioni event-sourced con CQRS separando assimilazione e consumo dei dati tramite pattern di comunicazione asincroni. I dati sono presi dai System of Records (SORs) e sono tramutati in proiezioni, garantendo un livello di dati coerente, strutturato, e ottimizzato per query efficienti. Questo approccio consente la separazione dei modelli di lettura e scrittura, migliorando le prestazioni e la scalabilità. Inoltre, Fast Data consente la creazione di visualizzazioni unificate aggregando i dati da più proiezioni, offrendo così un data layer costante, facilmente accessibile, e aggiornato in tempo reale.

Scoprite il video demo di Fast Data per una guida dettagliata sull’utilizzo di questa soluzione per implementare rapidamente Event Sourcing e CQRS.