EDA: inoltrare gli eventi

Negli scorsi articoli abbiamo imparato cosa sia un evento e cosa questo debba contenere, ma una volta costruito il nostro evento, come lo inviamo?

Broker e Mediator sono i due pattern più diffusi per la gestione degli eventi e, come in ogni altro aspetto della programmazione, ognuno ha i suoi pro e contro.

Questi pattern sono molto simili tra di loro, ma hanno una differenza fondamentale: il Broker si occupa di inoltrare gli eventi, mentre il Mediator si occupa di coordinare il passaggio degli eventi e la loro elaborazione.

Se volessimo fare un paragone, il Broker è simile ad un postino, ovvero un tramite che si occupa di consegnare messaggi da un mittente ad un destinatario in maniera rapida ed efficiente, mentre il Mediator è simile ad un maestro d’orchestra, che dirige l’orchestra e coordina le azioni dei singoli musicisti.

In entrambi i casi, il Broker e il Mediator si occupano di ricevere e inoltrare gli eventi, ma il modo in cui lo fanno è fondamentalmente diverso.

Broker

Il Broker è un pattern che si basa su un componente centrale, il Broker appunto, che si occupa di ricevere, elaborare e inoltrare gli eventi.

Questo pattern è molto diffuso in quanto permette di disaccoppiare l’intero sistema, in quanto il mittente non deve sapere chi riceverà l’evento e il destinatario non deve sapere chi ha inviato l’evento.

Inoltre permette di scalare il sistema in maniera semplice, in quanto è possibile aggiungere o rimuovere destinatari senza dover modificare alcuna componente.

Un Broker è spesso accompagnato da un event channel, ovvero un canale nel quale vengono inoltrati gli eventi. Questo canale può essere un sistema di code, un sistema di pub-sub, o anche un canale di comunicazione diretta, come ad esempio una connessione WebSocket.

La comodità di un Broker è la sua semplicità, sia in termini di implementazione che di utilizzo.

Se volessimo schematizzare un Broker, potremmo farlo in questo modo:

Alcuni dei Broker più famosi sono RabbitMQ, Kafka e Amazon SQS, ma è possibile implementare un Broker anche con soluzioni più semplici, come Redis, tenendo conto che queste non offriranno le stesse garanzie di affidabilità e scalabilità delle soluzioni più complesse, ma saranno comunque valide per la maggior parte delle casistiche e ridurranno la complessità generale del sistema.

Mediator

Il Mediator è un pattern che si basa su un componente centrale, il Mediator appunto, che si occupa di coordinare le azioni che avvengono al suo interno.

Questo pattern è molto diffuso in situazioni in cui è necessario effettuare varie operazioni in risposta ad un evento, ad esempio in un sistema di automazione.

Spesso, quando si parla di Mediator, si prende ad esempio il mercato azionario. Quando si piazza un ordine di acquisto o vendita, questo ordine subirà varie operazioni, come la verifica del saldo, la verifica della disponibilità del titolo, il rispetto delle regole di compliance, l’applicazioni delle commissioni, ecc. Queste operazioni devono necessariamente essere orchestrate da un componente centrale, in quanto il risultato di una operazione può influenzare il comportamento e il risultato delle altre.

Solitamente, per supportare queste necessità, il Mediator è accompagnato da più event channel. Ognuno di questi canali sarà ascoltato da dei destinatari, che si occuperanno di reagire all’evento.

La capacità di coordinare le azioni di altri componenti è la forza del Mediator, ma è anche la sua debolezza, in quanto impone una maggiore complessità sia in termini di implementazione che di utilizzo.

Una nota importante riguarda la business logic: il Mediator non deve contenere business logic, ma deve limitarsi a coordinare le azioni degli altri componenti in risposta ad un evento. Questo è un prerequisito fondamentale per garantire la manutenibilità del sistema.

Se volessimo schematizzare un Mediator, potremmo farlo in questo modo:

Le soluzioni più famose per implementare un Mediator sono MediatR e MassTransit.

Multi-Broker Pattern

Un pattern che sta prendendo sempre più piede nel mondo delle EDA è il Multi-Broker Pattern, ovvero l’utilizzo di più Broker in un sistema. Questo pattern è utile in situazioni in cui è necessario gestire un alto volume di eventi, ma non si vuole perdere la semplicità che il Broker pattern offre.

Ipotizziamo di avere un sistema di 10 microservizi in cui ogni servizio emette e riceve eventi e, in una situazione tipo, potremmo dover gestire un carico di lavoro pari a 3.000 eventi al secondo per microservizio. Il totale di eventi da gestire sarà quindi di 30.000 eventi al secondo. Ipotizziamo di avere un solo Broker in grado di gestire 20.000 eventi al secondo. In questo caso, il nostro sistema non sarebbe in grado di gestire il carico di lavoro richiesto e andrebbe in sovraccarico.

Ecco quindi che entra in gioco il Multi-Broker Pattern: possiamo affiancare all’attuale Broker un secondo Broker, in modo che il carico di lavoro venga distribuito tra i due Broker. I nostri microservizi, quindi, invieranno gli eventi ad uno dei due Broker tramite un load balancer, o un meccanismo di round-robin, distribuendo così il carico di lavoro tra i due Broker, che ora avranno una capacità totale di 40.000 eventi al secondo e saranno in grado di gestire il carico di lavoro richiesto.

Mentre da un lato questo pattern aumenta la scalabilità, le performance e la capacità del nostro sistema, dall’altra aumenta i costi, la complessità e ci fa perdere una caratteristica principale del Broker: L’ordinamento FIFO(First In, First Out) degli eventi. Infatti, se un evento viene inviato ad un Broker e questo viene inoltrato ad un destinatario, non possiamo garantire che ciò accadrà prima che un altro evento venga inviato ad un altro Broker e inoltrato allo stesso destinatario.

Conclusioni

In conclusione, sia il Broker che il Mediator sono due pattern validi per la gestione degli eventi, ma bisogna valutare con attenzione le proprie necessità prima di prendere una decisione.

Nel mondo reale, spesso il Broker è considerato il pattern più adatto in quanto la semplicità con cui è possibile implementarlo e gestirlo supera i suoi difetti, inoltre passare ad un Multi-Broker risulterebbe più semplice rispetto ad una migrazione verso un Mediator.

Tuttavia, in situazioni in cui è necessario coordinare le azioni di più componenti, il Mediator risulta essere la scelta migliore in quanto, ad una prima difficoltà di implementazione, seguirà una maggiore manutenibilità e scalabilità del sistema.

Per saperne di più, leggi il capitolo dedicato alle architetture de “Il Libro Open Source”.