L'architettura event-driven (EDA) è un modo di costruire software in cui le parti di un sistema comunicano annunciando che è accaduto qualcosa, invece di chiamarsi direttamente. Un componente pubblica un evento, come “fattura pagata” o “contratto firmato”. Qualsiasi altro componente interessato vi reagisce. Nessuna delle due parti ha bisogno di sapere che l'altra esiste.

Per un'azienda SaaS, questo conta ben oltre l'ambito ingegneristico. La stessa idea sta alla base di passaggi puliti dal CRM alla finanza, di un'automazione affidabile e di agenti AI che operano su dati aggiornati. Questa guida spiega come funziona l'EDA, in cosa un event bus si differenzia da una coda, come evitare i fallimenti più comuni e dove l'EDA trova applicazione e dove no.

In sintesi

Indice

Che cos'è l'architettura event-driven

Le linee guida di Microsoft sull'architettura descrivono questo stile come produttori di eventi che generano un flusso di eventi, consumatori di eventi che li ascoltano e canali di eventi che trasportano gli eventi dagli uni agli altri. Questo modello in tre parti è l'idea nella sua interezza. Tutto il resto è dettaglio su quanto il canale sia affidabile e veloce.

Il contrasto è con il modello request/response. In un design request/response, il vostro servizio di fatturazione chiama il CRM e attende una risposta. Se il CRM è lento o non disponibile, la fatturazione resta bloccata. In un design event-driven, la fatturazione pubblica “pagamento ricevuto” e prosegue. Il CRM, il report sui ricavi e la dashboard del successo dei clienti raccolgono ciascuno l'evento quando sono pronti.

Da qui derivano due proprietà:

Che cosa conta come evento

Un evento è un'affermazione di fatto al passato. Red Hat lo descrive come una registrazione immutabile del fatto che qualcosa è accaduto, spesso con un timestamp che preserva l'ordine rispetto al sistema che lo ha prodotto. Un evento non si modifica a posteriori. Se qualcosa cambia, un nuovo evento registra il cambiamento.

AWS osserva che gli eventi possono essere un cambiamento di stato o un aggiornamento, e possono trasportare lo stato oppure essere identificatori. Due esempi:

Stile Esempio Che cosa riceve il consumatore
Evento che trasporta lo stato Abbonamento aggiornato, con piano, prezzo, data di decorrenza, ID account Tutto il necessario per agire senza una seconda consultazione
Evento come identificatore Ordine spedito, con il solo ID dell'ordine Un segnale. Il consumatore recupera i dettagli dal sistema di origine

Il primo è comodo, ma lega i consumatori alla struttura dell'evento. Il secondo mantiene gli eventi leggeri, ma rimanda i consumatori al sistema di origine, il che solleva la questione di quale sistema sia la fonte di riferimento. Ci torniamo più avanti, perché è il punto in cui si inceppano la maggior parte degli stack operativi SaaS.

Un comando non è un evento. “Invia la fattura” è un'istruzione rivolta a un destinatario specifico. “Fattura inviata” è un fatto a cui chiunque può reagire. Confondere i due è un errore di progettazione comune e ricostruisce silenziosamente lo stretto accoppiamento che si voleva eliminare.

Come funziona un sistema event-driven, passo dopo passo

La documentazione di Google Cloud descrive il flusso: i producer generano eventi, un router o broker li riceve e li filtra, quindi li distribuisce ai consumer in base a sottoscrizioni o trigger. In pratica:

  1. Succede qualcosa. Una trattativa passa a “Closed Won” nel CRM.
  2. Il producer pubblica un evento. L’evento dichiara il fatto e il record a cui si riferisce.
  3. Il broker lo instrada. Filtra l’evento e lo consegna a ogni subscriber.
  4. I consumer reagiscono in modo indipendente. Il reparto Finance crea una bozza di fattura. Il Customer Success apre un piano di onboarding. Un processo di provisioning prepara gli accessi.
  5. Ogni consumer conferma la ricezione. Il broker sa che l’evento è stato gestito e, in caso contrario, può riprovare.

IBM descrive lo stesso pattern come pubblicazione, acquisizione, elaborazione e archiviazione degli eventi e sottolinea che il valore di un evento può cambiare nel tempo. Un evento “nuovo lead” richiede un’azione nel giro di pochi minuti. Un anno dopo è utile soprattutto per l’analisi.

Architettura event-driven e microservizi

Spesso si considerano la stessa cosa. Non lo sono. I microservizi descrivono come si suddivide un’applicazione in piccoli servizi distribuiti in modo indipendente. L’EDA descrive come questi servizi comunicano. Si possono avere microservizi che si chiamano a vicenda in modo sincrono, e si può avere un’applicazione monolitica che pubblica eventi al proprio interno.

I due approcci funzionano bene insieme. Le indicazioni di Google osservano che i microservizi possono reagire in modo asincrono agli eventi e devono conoscere solo il formato dell’evento, non la logica di business degli altri. Quel formato condiviso è il contratto. Tutto ciò che sta dietro può cambiare.

La documentazione di Microsoft descrive il pattern tipico come microservizi che pubblicano un evento quando accade qualcosa di rilevante, mentre altri microservizi si sottoscrivono.

Event bus, coda e stream a confronto

Questi tre termini generano più confusione di tutti, e la scelta cambia il comportamento del sistema.

Event bus (publish/subscribe). Un event bus è un meccanismo in cui i publisher annunciano gli eventi e i subscriber li ricevono. Microsoft spiega che può essere implementato su un’infrastruttura di messaggistica come una coda o un service bus che supporti il publish/subscribe asincrono. Quindi una coda può essere uno dei componenti di un bus. Il bus è l’intento. La coda è un modo per realizzarlo.

Coda. Una coda conserva i messaggi finché un worker non li preleva. Ogni messaggio viene normalmente gestito da un solo consumer. Le code sono lo strumento giusto per distribuire il lavoro tra più worker e per assorbire i picchi. Le linee guida di Azure sull’integrazione indicano tra i motivi per usare un broker l’accodamento dei messaggi quando un back end non è disponibile.

Event stream. Azure distingue il publish/subscribe dallo streaming. Nel publish/subscribe, una volta ricevuto, l’evento non viene conservato in un log durevole, quindi i nuovi subscriber non vedono gli eventi passati. Nello streaming gli eventi vengono scritti in un log durevole e rigorosamente ordinato all’interno di una partizione, e i client leggono dal log, possono unirsi in qualsiasi momento e rieseguire gli eventi.

Coda Bus publish/subscribe Event stream
Consegna Un consumer per messaggio Ogni subscriber Qualsiasi lettore, da qualsiasi punto
Eventi passati Rimossi dopo l’elaborazione Non disponibili per i nuovi subscriber Conservati e rieseguibili
Uso tipico Distribuzione del lavoro, buffering Notifica a più sistemi Storico, analisi, ricostruzione dello stato

Una regola pratica: se più sistemi devono reagire allo stesso fatto, usate il publish/subscribe. Se serve un solo worker per svolgere un compito, usate una coda. Se serve lo storico o la possibilità di ricostruire un sistema a valle, usate uno stream. Red Hat aggiunge che non esiste una soluzione valida per tutti i casi, quindi la tecnologia va scelta in base al tipo di evento.

Kafka è un'architettura event-driven?

No. Kafka è una tecnologia che si può usare per costruirne una. La documentazione di Apache Kafka lo descrive come una piattaforma per l’event streaming: acquisire eventi in tempo reale, archiviarli in modo durevole, elaborarli e instradarli verso altri sistemi. Ciò lo rende un event stream, nella tabella qui sopra.

Un’architettura è un insieme di decisioni di progettazione: quali sono gli eventi, a chi appartengono, come vengono isolati i consumer, che cosa accade in caso di guasto. Queste decisioni si possono prendere ed eseguire su un bus cloud gestito, su un servizio di code o su Kafka. Si può anche usare Kafka e avere comunque un sistema fortemente accoppiato, se ogni servizio dipende dagli eventi interni di un altro servizio. Scegliete lo strumento dopo aver definito gli eventi e il volume che prevedete realmente.

Integrazione e automazione event-driven

Qui l’EDA diventa rilevante per chi guida le operations, e non solo per gli ingegneri.

Integrazione

La maggior parte delle aziende SaaS collega CRM, fatturazione, supporto e dati di prodotto con sincronizzazioni punto a punto. Ogni nuovo strumento aggiunge un’altra connessione da mantenere. Azure raccomanda la comunicazione asincrona tramite un message broker al posto delle chiamate sincrone dirette, per quattro motivi che elenca: disaccoppiare le applicazioni, trasmettere a più consumer, tracciare in modo affidabile i workflow di lunga durata e accodare i messaggi quando un back end non è disponibile.

Il vantaggio emerge quando si aggiunge un sistema. Con un servizio publish/subscribe, è possibile aggiungere nuovi subscriber senza modificare il mittente. Aggiungere un nuovo strumento di analisi non richiede alcuna modifica al CRM.

Automazione

L’automazione event-driven significa che un processo aziendale parte perché è successo qualcosa, non perché qualcuno ha cliccato un pulsante o è stato eseguito un job notturno. La guida ai flow di ServiceNow propone un metodo pratico: individuare il trigger, pianificare la logica, selezionare le azioni e individuare la logica riutilizzabile. Raccomanda inoltre di mantenere i flow mirati e di usare un solo verbo per azione.

Quando un processo coinvolge più servizi, Microsoft osserva che i sistemi event-driven usano comunemente pattern di coreografia e di orchestrazione saga per coordinare il flusso. Nella coreografia, ogni servizio reagisce agli eventi ed emette i propri. Nell’orchestrazione, un coordinatore indica a ogni passaggio che cosa fare e tiene traccia dell’intero processo. Per un primo progetto, un flusso orchestrato è di solito più facile da leggere e da verificare.

Un semplice esempio SaaS:

Buone pratiche e sfide comuni

Azure elenca le principali sfide: coerenza eventuale, gestione asincrona degli errori, perdita di dati, osservabilità e test, eventi troppo numerosi o eccessivamente aggregati ed evoluzione degli schemi. Ognuna ha una pratica corrispondente.

  1. Pianificate la coerenza eventuale. I sistemi per un breve periodo non saranno allineati. Decidete quale sistema è l'autorità per ciascun dato e lasciate che gli altri lo seguano.
  2. Aggiungete un gestore degli errori dedicato. Gli eventi falliti hanno bisogno di un posto dove andare e di qualcuno che li esamini.
  3. Conservate gli eventi finché la ricezione non è confermata. Questo protegge dalla perdita di dati quando un consumer non è attivo.
  4. Usate i correlation ID. Un unico ID portato attraverso ogni passaggio permette di tracciare una singola azione del cliente tra i diversi sistemi.
  5. Bilanciate la granularità degli eventi. Un evento per ogni modifica di campo crea rumore. Un unico evento gigante per tutto ricrea l'accoppiamento.
  6. Versionate gli schemi fin da subito. I formati degli eventi cambieranno. Decidete come gestirlo prima di avere venti consumer.

A queste aggiungeremmo tre abitudini operative: dare agli eventi nomi al passato, assegnare a ogni tipo di evento un unico responsabile e annotare quali consumer ne dipendono.

Dove il design event-driven non va usato

L'EDA non è la risposta a ogni problema. Siate espliciti sui limiti prima di impegnarvi:

La stessa logica vale per l'AI. Un assistente AI che legge i vostri sistemi e agisce su di essi è al tempo stesso consumer e producer di eventi. Se legge dati incoerenti o agisce senza un perimetro di permessi, avete un modo più rapido per generare errori.

Dove l'EDA incontra gli agenti AI e la conformità

Gli agenti AI che prelevano dati (chiedono, riportano, consultano) e inviano dati (aggiornano un record, avviano un processo, assegnano accessi) si comportano come partecipanti di un sistema event-driven. Hanno bisogno di una fonte affidabile da leggere, di un insieme chiaro di azioni consentite, di un'approvazione per i passaggi sensibili e di una traccia di ciò che hanno fatto. Un registro degli eventi è il luogo naturale per questa traccia.

Operatore che esamina il registro eventi di un agente AI

Per le aziende europee, GDPR, NIS2 e EU AI Act incidono tutti sul modo in cui questi sistemi vengono progettati. In termini generali, riguardano quali dati personali transitano negli eventi, come sono organizzate la sicurezza e la gestione degli incidenti, e come i sistemi di AI sono governati e documentati. Trattateli come requisiti di progettazione fin dall'inizio e chiedete un parere a un legale su come si applicano al vostro caso specifico. Nessuna scelta architetturale, da sola, rende un sistema conforme.

La nostra prospettiva

La maggior parte delle aziende SaaS con cui parliamo non ha un problema di eventi. Ha un problema di responsabilità. Diversi team usano l'AI, diversi strumenti contengono una versione del cliente e nessuno è responsabile di stabilire quale versione sia quella giusta.

Per questo lavoriamo secondo un ordine preciso. Prima la data foundation: i dati di CRM e finanza come fonte di verità concordata. Poi il livello AI, che collega quei dati all'assistente che il vostro team usa già. Poi gli agenti di reparto per Finance, Sales e Customer Success. Gli eventi sono utili in tutti e tre i livelli, ma servono solo quando i fatti che trasportano sono stati concordati.

Inoltre adottiamo un processo alla volta, partendo da quello più costoso. Un processo di rinnovo o il passaggio dalla fattura all'incasso è un primo progetto event-driven migliore di una ricostruzione dell'intera azienda. Vedete il risultato, le vostre persone imparano lo schema e il processo successivo costa meno.

Poiché gestiamo le operazioni oltre a progettare i sistemi, ci prendiamo cura degli aspetti poco appariscenti: permessi, approvazioni, tracce di audit e un passaggio di consegne in cui codice, documentazione e infrastruttura diventano di vostra proprietà.

Claus Nielsen

Come iniziare nella propria azienda

Non dovete scegliere prima un broker. Iniziate con queste domande:

  1. Quale processo vi costa di più in lavoro manuale, ritardi o errori?
  2. Quali sono i due o tre eventi che lo avviano (ad esempio contratto chiuso, fattura scaduta, rinnovo in arrivo)?
  3. Quale sistema è la fonte di verità per i dati di quegli eventi?
  4. Chi è responsabile di ciascuna definizione di evento?
  5. Quali passaggi richiedono l'approvazione di una persona?

Se non sapete rispondere alla terza domanda, viene prima la data foundation. Se invece sì, un piccolo progetto pilota su un processo vi mostrerà se un approccio event-driven è conveniente.

Come possiamo aiutarvi

Se il vostro team usa l'AI ma nessuno ne è responsabile, possiamo aiutarvi a decidere dove conviene e a costruirla nell'ordine giusto. Il nostro AI Readiness Assessment è disponibile a partire da €4,500 ed esamina i vostri dati, sistemi e processi prima che venga costruito qualsiasi cosa. Se desiderate una guida continuativa, il servizio di Fractional Chief AI Officer parte da €1,500 al mese.

Le realizzazioni sono prezzate al 30% di un risparmio del primo anno misurato e dimostrato, oppure a un prezzo fisso concordato prima dell'inizio dei lavori. Potete anche prenotare una call conoscitiva gratuita di 30 minuti attraverso il nostro sito. I nostri agenti AI per Finance, Sales e Customer Success mostrano come si presenta il livello di reparto una volta predisposta la base.

FAQ

Che cos'è l'architettura event-driven in termini semplici?

È un modello di progettazione in cui i componenti software annunciano che è successo qualcosa e altri componenti reagiscono. Chi invia non sa chi è in ascolto. Questo permette di aggiungere o modificare sistemi senza riscrivere quelli che producono gli eventi.

Qual è la differenza tra un event bus e una coda di messaggi?

Una coda in genere consegna ogni messaggio a un solo worker. Un event bus consegna ogni evento a tutti i sottoscrittori. Un bus può essere costruito su un'infrastruttura di code, quindi la differenza sta nell'intento e nel modello di consegna, non sempre nel prodotto.

L'architettura event-driven è la stessa cosa dei microservizi?

No. I microservizi riguardano il modo in cui un'applicazione viene suddivisa in servizi. L'architettura event-driven riguarda il modo in cui le parti comunicano. Spesso vengono usate insieme, ma ciascuna può esistere senza l'altra.

Quando un'azienda SaaS dovrebbe usare l'automazione basata sugli eventi?

Va usata quando un processo aziendale deve partire da un fatto, come una trattativa chiusa o un rinnovo in arrivo, e diversi team o sistemi devono reagire. Si parte da un singolo processo costoso, dopo aver verificato che i dati di origine siano stati concordati.

Fonti