Event-Driven Architecture (EDA): Programmazione basata su eventi

L'Event-Driven Architecture (EDA) è un paradigma software dove le applicazioni comunicano attraverso eventi, in modo asincrono e disaccoppiato. È il cuore di molte architetture moderne come i microservizi, i sistemi IoT, e le app real-time.

🔗 Ti piace Techelopment? Dai un'occhiata al sito per tutti i dettagli!

Cos'è un'Event-Driven Architecture?

L’Event-Driven Architecture (EDA) è un modello architetturale in cui i componenti del sistema comunicano e reagiscono attraverso eventi. Invece di richiedere continuamente lo stato di altri componenti (come accade nei sistemi sincroni), ogni componente rimane in attesa di eventi significativi e agisce solo quando questi si verificano.

Un evento rappresenta un cambiamento di stato o un’azione rilevante per il sistema, ad esempio:

“Un ordine è stato creato”
“Un pagamento è stato approvato”
“Un sensore ha rilevato una temperatura anomala”

Componenti Principali di un'EDA

Event Producer (Produttore di eventi)

È il componente che genera un evento quando accade qualcosa di rilevante. Il produttore non sa né chi consumerà l’evento né come verrà gestito.
Event Consumer (Consumatore di eventi)

È il componente che riceve e reagisce a un evento. Può esserci uno o più consumatori per lo stesso evento.
Event Channel (Canale degli eventi)

È il mezzo attraverso cui gli eventi vengono trasmessi. Può essere un message broker come Kafka, RabbitMQ, AWS EventBridge o semplici code (queues).
Event (Evento)

È il messaggio che descrive ciò che è accaduto. Solitamente è strutturato come un oggetto JSON o XML che contiene un tipo, un timestamp e i dati rilevanti.

Come Funziona un Sistema EDA?

Flusso base:

Un utente effettua un'azione (es. invia un ordine).

Il sistema genera un evento:

{ 
   tipo: "OrdineCreato", 
   dati: { 
      id: 123, 
      utente: "Marco"
   }
}

L’evento viene pubblicato sul canale eventi.
I consumatori interessati (es. sistema di pagamento, sistema di notifiche) ricevono l’evento e reagiscono in modo autonomo.

EDA

Tipologie di Comunicazione

Asincrona: La regola generale. I componenti non aspettano risposte immediate.
Disaccoppiata: I produttori e i consumatori non sono direttamente collegati.
Pub/Sub (Publish/Subscribe): I produttori pubblicano eventi, e chi è interessato si “iscrive” per riceverli.

Vantaggi dell’EDA

✅ Scalabilità: Ogni componente può scalare indipendentemente in base al carico degli eventi.

✅ Decoupling (disaccoppiamento): I componenti sono autonomi e non hanno bisogno di conoscere gli altri, favorendo la manutenibilità e l’evoluzione del sistema.

✅ Reattività: Il sistema può rispondere rapidamente a condizioni esterne o interne.

✅ Audit & Logging naturali: Gli eventi creano una traccia storica naturale di ciò che è accaduto nel sistema.

Svantaggi dell’EDA

⚠️ Debugging complesso: Tracciare il percorso di un evento può essere difficile in ambienti distribuiti.

⚠️ Gestione delle dipendenze temporali: Gli eventi possono arrivare in ordine sbagliato, o più volte, o essere persi senza i giusti meccanismi.

⚠️ Difficoltà di testing: Testare sistemi asincroni richiede strategie specifiche.

⚠️ Contratti deboli: Senza una struttura comune per gli eventi, la comunicazione può diventare fragile (es. un cambiamento in un evento può rompere i consumatori).

Esempio Pratico

Immaginiamo un’app di e-commerce:

Utente effettua un ordine
Il sistema pubblica un evento OrdineCreato
Tre servizi reagiscono:
- Servizio Pagamenti → prepara la fattura
- Servizio Notifiche → invia un'email
- Servizio Logistica → prepara la spedizione

Nessuno di questi servizi deve chiamare direttamente l'altro. Ognuno ascolta gli eventi e agisce secondo la propria logica.

Tecnologie Popolari per EDA

Apache Kafka
RabbitMQ
Amazon SNS/SQS (in combinazione con AWS Lambda)
Azure Event Grid
Google Pub/Sub
NATS, Redis Streams, MQTT (per IoT)

☁️ Esempio con AWS Lambda + SQS (Node.js)

🎯 Obiettivo

Quando un messaggio viene inviato a una coda SQS, una funzione AWS Lambda si attiva automaticamente, legge il messaggio ed esegue una logica (es. stampa dell’ordine ricevuto, invio e-email, ecc.).

🧱 Struttura dell’architettura

Esempio di flusso

⚙️ 1. Creazione della Coda SQS

Accedi alla console: https://console.aws.amazon.com/sqs
Clicca su “Create Queue”
Imposta:
- Tipo: Standard
- Nome: OrdiniQueue
Lascia le altre impostazioni predefinite e crea la coda

🖥️ 2. Creazione della Funzione Lambda

Vai su: https://console.aws.amazon.com/lambda
Clicca su “Create function”
Imposta:
- Nome funzione: GestioneOrdini
- Runtime: Node.js 18.x (o simile)
- Autorizzazioni: crea un nuovo ruolo con autorizzazioni base
Clicca su “Create Function”

📎 3. Collegare SQS come trigger della Lambda

All’interno della funzione Lambda, clicca su "Add trigger"
Seleziona:
- Servizio: SQS
- Coda: seleziona OrdiniQueue
Salva

Questo collega la coda alla funzione Lambda: ogni nuovo messaggio attiva automaticamente la funzione.

✏️ 4. Scrivere il codice della Lambda

Nel pannello della tua Lambda, scorri in basso fino a “Code”.

Sostituisci il codice con questo:

// handler.js
exports.handler = async (event) => {
  for (const record of event.Records) {
    const ordine = JSON.parse(record.body);
    console.log(`📦 Ordine ricevuto: ID ${ordine.id}, Cliente: ${ordine.cliente}, Importo: €${ordine.importo}`);
    // Qui puoi inserire logica di notifica, invio e-mail, salvataggi su DB, ecc.
  }

  return {
    statusCode: 200,
    body: JSON.stringify('Ordine gestito con successo'),
  };
};

📌 La funzione viene invocata con un event contenente un array di messaggi SQS (event.Records)

📤 5. Inviare un messaggio alla coda

Puoi farlo in due modi:

A. Via Console AWS:

Vai su SQS > OrdiniQueue > “Send and receive messages”
Inserisci un JSON come questo:

{
  "id": 123,
  "cliente": "Marco",
  "importo": 89.90
}

Clicca “Send Message”

B. Via AWS CLI:

>aws sqs send-message \
  --queue-url https://sqs.<regione>.amazonaws.com/<account-id>/OrdiniQueue \
  --message-body '{"id": 123, "cliente": "Marco", "importo": 89.90}'

Sostituisci <regione> (es. eu-west-1) e <account-id> con i tuoi valori.

✅ Risultato Atteso

Ogni volta che invii un messaggio alla coda:

Lambda si attiva automaticamente
Il messaggio viene letto
Viene stampato nei log della funzione Lambda

👉 Vai su Monitoraggio > View logs in CloudWatch per vedere l'output!

🧠 Cosa hai ottenuto

Architettura event-driven serverless
Nessun server da gestire
Reattività e scalabilità automatica
Logica scritta in Node.js con deployment istantaneo

🔐 Permessi (IAM Policy)

Assicurati che la Lambda abbia accesso alla coda SQS. Se hai usato le impostazioni predefinite, AWS lo fa automaticamente. Altrimenti, il ruolo della Lambda deve avere almeno questa policy:

{
  "Effect": "Allow",
  "Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"],
  "Resource": "arn:aws:sqs:REGIONE:ACCOUNT_ID:OrdiniQueue"
}

Quando Usare un'Event-Driven Architecture?

✅ Quando serve alta scalabilità
✅ Quando vuoi decoupling tra componenti
✅ Per sistemi con molti eventi asincroni o real-time
✅ Per microservizi complessi con flussi reattivi

Non è ideale per sistemi molto semplici o in cui la consistenza immediata è cruciale senza tolleranza a ritardi.

Conclusione

L’Event-Driven Architecture è un paradigma potente e flessibile per costruire sistemi moderni, resilienti e scalabili. Richiede una buona progettazione e attenzione ai dettagli (come la gestione degli errori, l’ordine degli eventi, l’idempotenza), ma offre enormi benefici soprattutto in ambienti distribuiti o a microservizi.

Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment

Techelopment

Cerca nel blog