Che cos'è l'architettura orientata agli eventi (EDA)?

L’architettura orientata agli eventi è uno stile di progettazione in cui i servizi annunciano fatti immutabili come eventi e i consumatori reagiscono da soli. La precisione che le pagine dei fornitori saltano sta in due parole: un evento è un fatto immutabile, al passato – OrderPlaced, non PlaceOrder – e il produttore non sa chi reagisce, né gli interessa. Quell’indifferenza è l’architettura: i consumatori si aggiungono, si rimuovono e si rompono senza che il produttore cambi una riga, ed è il disaccoppiamento nel senso più letterale. E l’EDA è uno spettro, non una religione – un singolo webhook è orientato agli eventi; lo è anche una piattaforma di streaming; la maggior parte dei sistemi sani è ibrida.

Punti chiave

Un fatto, molte reazioni

// JavaScript — Cloud Code (cloud/main.js)
// Everyday EDA: the write IS the event; consumers react independently
Parse.Cloud.afterSave('Order', async (req) => {
  const order = req.object;
  const becamePlaced = order.get('status') === 'placed' &&
    req.original?.get('status') !== 'placed';
  if (!becamePlaced) return;

  // Consumers of one fact — none knows about the others:
  await Parse.Cloud.httpRequest({          // fulfillment system (webhook)
    method: 'POST', url: process.env.FULFILL_WEBHOOK,
    body: { event: 'order.placed', id: order.id },
  });
  await enqueueConfirmationEmail(order);   // async job queue
  // Live Query pushes the change to every open dashboard automatically
});

// Flutter / Dart — Back4app Flutter SDK
// The client as event consumer: subscribe to facts, react on arrival
final orders = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'placed');
final sub = await LiveQuery().client.subscribe(orders);
sub.on(LiveQueryEvent.create, (order) => showNewOrder(order));
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// iOS / Swift — Back4app Swift SDK
// The client as event consumer: subscribe to facts, react on arrival
let orders = Order.query("status" == "placed")
let sub = try await orders.subscribe()
sub.handleEvent { _, event in
    if case .created(let order) = event { showNewOrder(order) }
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

// Android / Kotlin — Back4app Android SDK
// The client as event consumer: subscribe to facts, react on arrival
val orders = ParseQuery.getQuery<ParseObject>("Order")
orders.whereEqualTo("status", "placed")
val sub = ParseLiveQueryClient.Factory.getClient().subscribe(orders)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, order ->
    showNewOrder(order)
}
// Nobody called this screen — it REACTED to an event, like every
// other consumer of "order placed": fulfillment, email, analytics.

Un fatto – un ordine è stato effettuato – e quattro consumatori, nessuno dei quali conosce gli altri: un sistema di evasione avvisato per webhook, un job di e-mail messo in coda, l’analytics che conta, le dashboard aggiornate da una sottoscrizione in diretta. Aggiungere un quinto consumatore non cambia nulla a monte. Tutto l’argomento sta in un solo salvataggio.

Il vocabolario, districato

Il caos terminologico dei risultati di ricerca, risolto in una tabella – tre tipi di messaggio classificati per intenzione, non per trasporto:

L’avvertimento di Fowler merita di essere citato: attenzione al comando passivo-aggressivo – un “evento” che il produttore emette pretendendo in segreto l’azione di un consumatore preciso. Se il flusso si rompe quando quel consumatore non risponde, era un comando dall’inizio, e chiamarlo evento ha solo nascosto l’accoppiamento. (Le parole dell’infrastruttura – broker, router, bus, canale, topic – sono quasi sinonimi per la casella centrale; la voce sul pub/sub copre quella meccanica, di cui l’EDA è l’architettura che generalizza.)

Orientato agli eventi vs. richiesta-risposta

La regola in una frase: se chi chiama ha bisogno del risultato per proseguire, richiesta-risposta; se il lavoro del produttore è concluso prima che inizi qualsiasi reazione, eventi. Effettuare l’ordine esige una risposta sincrona (“è andato a buon fine?”); tutto ciò che viene dopo – e-mail, evasione, analytics – sono reazioni a un fatto, ed è per questo che i sistemi reali sono ibridi per progetto e non per compromesso.

Le tre varianti di Fowler – e dove si colloca davvero l’event sourcing

La distinzione che risparmia riunioni: l’event sourcing è il modo in cui un sistema archivia i dati; l’EDA è il modo in cui i sistemi comunicano. I due si combinano, ma nessuno dei due richiede l’altro. Un’altra riga che i fornitori sfumano: la consegna pub/sub dimentica – chi si sottoscrive in ritardo perde ciò che è scattato prima del suo arrivo – mentre lo streaming (il log ordinato in stile Kafka) ricorda, e lascia ai consumatori il replay da qualunque punto; la scelta dipende da quanto la storia faccia parte del prodotto.

Coreografia vs. orchestrazione

La regola specchiata, condivisa con la voce sull’orchestrazione: orchestrare quando qualcuno deve rispondere del risultato di un workflow; coreografare quando ai produttori davvero non importa cosa accade dopo. Le lunghe transazioni di business fra servizi prendono in entrambi i casi la forma di una saga – transazioni locali concatenate da eventi oppure da un orchestratore, annullate da compensazioni anziché da un rollback.

EDA quotidiana – senza broker

La sezione che i portali di architettura non scrivono mai: la maggior parte di chi sviluppa applicazioni pratica già pattern orientati agli eventi senza un broker di messaggi all’orizzonte. Un trigger beforeSave/afterSave è un consumatore di eventi di modifica dei dati. Un webhook è un evento che attraversa i confini fra aziende su semplice HTTP. Una live query è pub/sub con i client come subscriber. Un job in background accodato da un trigger è un evento che genera lavoro asincrono. Le schede di codice qui sopra sono esattamente questo stack – la scrittura è l’evento, il trigger è il router, e i consumatori sono un webhook, una coda e una sottoscrizione. I broker dedicati (Kafka, RabbitMQ, NATS – con CloudEvents come busta standard) si guadagnano il proprio peso operativo quando volume di eventi, replay e contratti fra team lo impongono; l’architettura comincia molto prima, e la domanda “serve un broker?” di solito si risponde da sé: non ancora.

Casi d’uso tipici

• Flussi di ordini e pagamenti – un fatto, molti reparti: la pipeline e-commerce canonica.
• Integrazione fra sistemi – servizi di team diversi che reagiscono senza chiamate dirette né deployment condivisi.
• Funzionalità in tempo reale – dashboard, feed e presenza come consumo di eventi lato client.
• Carichi a picchi – code che fanno da buffer alle raffiche, perché i consumatori le smaltiscano con i propri tempi.
• Audit e replay – log di streaming in cui “che cosa è accaduto, e in che ordine” è il prodotto stesso.

Conviene passare agli eventi? Matrice decisionale

Limiti e trade-off

• Il debug perde lo stack di chiamate. Una richiesta che si dirama in cinque salti asincroni è tracciabile solo con ID di correlazione propagati dal primo evento – aggiungerli a posteriori è penoso; conviene collegarli dal primo giorno.
• L’eventual consistency arriva fino all’interfaccia. L’utente modifica il profilo e la schermata successiva mostra il vecchio nome; o si progetta la UX per questo, o quel percorso resta sincrono.
• I duplicati sono contrattuali. La consegna at-least-once rende obbligatori i consumatori idempotenti – lo stesso contratto che impongono le code, perché è la stessa meccanica.
• Gli schemi evolvono sotto i piedi dei consumatori. Gli eventi sono contratti con subscriber sconosciuti: solo modifiche additive, topic versionati per le modifiche incompatibili e lettori tolleranti in ogni punto.
• I workflow emergenti si nascondono. La coreografia pura significa che nessuno può puntare il dito sul processo di business; quando serve a chi fa audit o a chi è in reperibilità, si aggiunge l’orchestratore.

I pattern orientati agli eventi su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La sezione sull’EDA quotidiana è il suo elenco di funzionalità letto come architettura: ogni salvataggio è un evento, i trigger afterSave sono consumatori lato server con tutto l’ecosistema JavaScript, le Live Queries diffondono i fatti verso i client su WebSocket gestiti, i webhook li portano verso sistemi esterni e i job in background assorbono le reazioni lente – le schede di codice mostrano l’intero ciclo a partire da un solo salvataggio di ordine. Le discipline su cui questo articolo insiste restano in mano a chi sviluppa (after-hook idempotenti, ragionamento al passato, sincrono dove chi chiama ha bisogno di risposte), mentre l’infrastruttura in forma di broker – fan-out, consegna, flotte di connessioni – arriva come comportamento della piattaforma, e passare più tardi a un broker di streaming dedicato è un’aggiunta a questa architettura, non una sua riscrittura.