Inbox & Outbox pattern - La consegna dei messaggi ai tempi moderni

Uno degli aspetti fondamentali dell'architettura dei microservizi è la gestione dei dati. Può capitare che un microservizio debba scambiarsi informazioni con un altro microservizio, questo scambio di informazioni può avvenire tramite API o tramite un broker di messaggi. Di solito, quando lo scambio di informazioni avviene tramite messaggi, è essenziale assicurarsi che il messaggio inviato raggiunga la sua destinazione e perderlo potrebbe comportare dei rischi aziendali.

Consideriamo un semplice scenario di esempio. Il microservizio A ha appena terminato di elaborare alcuni dati e li ha salvati sul database, ora deve notificare al microservizio B che ha terminato il suo compito e che sono disponibili nuove informazioni da recuperare.

La soluzione più semplice sarebbe semplicemente inviare una richiesta REST al microservizio B dopo aver salvato i dati sul database giusto? SBAGLIATO.

Questa casistica di esempio può presentare alcuni inconvenienti, il più importante è uno stretto legame tra i microservizi. Se il microservizio B è inattivo a causa di manutenzione o guasto, il messaggio non verrà recapitato se si utilizza una richiesta REST.

Aggiungendo un nuovo layer tra i microservizi, il broker di messaggi, si elimina il legame creato in precedenza. Il broker è responsabile della consegna di un messaggio al destinatario. Se B è inattivo, è compito del broker conservare il messaggio per tutto il tempo necessario per trasmetterlo correttamente. Qui ci viene in aiuto il pattern inbox/outbox.

Che cos'è il pattern Inbox/Outbox?

Il pattern Inbox/Outbox è un modo per gestire le operazioni di input/output asincrono in un sistema distribuito. Il pattern prevede che ogni operazione di input venga inserita in una "inbox" o "documenti in entrata" e che ogni operazione di output venga inserita in una "outbox" o "documenti in uscita".

Il primo step per sfruttare questo pattern è creare la nostra tabella che memorizzi tutti i messaggi da consegnare, questa sarà la nostra tabella di outbox.

Lo step successivo è creare un processo che lavori in background che, a intervalli pianificati, vada a controllare la presenza di nuovi dati nella tabella di outbox. Se viene trovato un messaggio non inviato, deve pubblicarlo (inviarlo a un broker esterno) e contrassegnarlo come inviato. 

L'ultimo step da eseguire è garantisce che il messaggio alla fine raggiunga il suo obiettivo. Nella maggior parte dei casi, non vogliamo semplicemente consegnare il messaggio. È anche importante assicurarsi che l'attività dal messaggio sia stata completata. Pertanto, è essenziale confermare la ricezione del messaggio solo dopo il completamento dell'attività. Se l'attività fallisce il messaggio non verrà confermato e verrà riconsegnato.

Una problematica in cui ci si può imbattere è la ricezione in inbox dello stesso messaggio più volte. Questo è causato perché in outbox lo stato del messaggio è ancora in sospeso (non è stato contrassegnato) poiché lo sta ancora elaborando, quindi il sistema lo invierà di nuovo e il destinatario riceverà un messaggio due volte. Ciò significa che l'outbox non impedisce le richieste duplicate, queste devono comunque essere gestite lato inbox o broker di messaggi. Una soluzione è rendere il nostro processo idempotente, il che significa che non importa quante volte viene inviato, in inbox verrà processato solo una sola volta.

Conclusione 

L'obiettivo di questo pattern è quello di gestire le operazioni di input/output in modo sicuro e affidabile. In particolare, il pattern Inbox/Outbox garantisce che le operazioni di input/output vengano eseguite in modo affidabile anche se il sistema viene riavviato o se si verificano errori di rete durante l'elaborazione delle operazioni.

Il pattern Inbox/Outbox viene spesso utilizzato in ambienti distribuiti per garantire la scalabilità e la disponibilità del sistema. Spero di averti convinto che questo pattern può essere una grande risorsa per aumentare la robustezza e l'affidabilità del tuo sistema.