Le migliori pratiche per la gestione delle comunicazioni inter asincrone?

Recentemente completato un progetto per la gestione dell'elaborazione della carta di credito. Una delle difficoltà che ho incontrato è stata la gestione del ritardo / possibile fallimento dei messaggi di notifica. L'esempio più complesso è stato:

• un sistema esterno che invia la richiesta di pagamento
• il mio sistema trasforma quella richiesta in una richiesta al gateway di pagamento
• invio dell'utente al gateway
• in attesa che l'utente esegua il pagamento
• l'utente ritorna nel mio sistema ma rimane in attesa fino a quando il sistema non riceve una notifica di successo / fallimento
• Invio dell'utente di nuovo al sistema esterno a seconda dell'errore

Ancora più difficile è stato il fatto che, in caso di mancato invio della notifica, il gateway tenta di inviare la notifica ogni 15 minuti per un numero di ore.

L'ho risolto utilizzando un record di database delle transazioni in sospeso e quindi rilevando l'esito positivo e negativo del reso più un listener di ritardo temporizzato per la notifica e la gestione delle transazioni ...

Ragionevolmente difficile!

Ma questo deve essere stato risolto un milione di volte prima, quindi qual è la migliore pratica?

Vedo che il mio futuro sta scrivendo la gestione tra tutti questi sistemi e la gestione dei ritardi e dei possibili guasti della rete, quindi voglio seguire le migliori pratiche.

I consigli su libri / articoli sarebbero fantastici.

Grazie in anticipo!

Quando si costruiscono sistemi distribuiti, la differenza tra un sistema "sincrono" e un sistema "asincrono" è questa: un sistema sincrono ha limiti superiori sui tempi di calcolo e consegna dei messaggi. Quindi: hai un sistema asincrono in cui alcuni eventi non hanno questi limiti superiori noti. Come lo gestisci?

1. Se questi processi asincroni hanno limiti superiori probabilistici, è possibile utilizzare i timeout per fare in modo che il sistema si comporti come un sistema parzialmente sincrono . Se il tempo di risposta del 98 ° percentile del gateway di pagamento è di 5 secondi, un periodo di tempo di 5 secondi farà sì che il 98% delle richieste abbia successo e l'altro 2% fallirà. Ciò significa che ora hai un limite superiore noto su quanto tempo impiegherà questo processo per avere successo o fallire. Questo rilevamento probabilistico di guasti è uno strumento fondamentale per trasformare i sistemi asincroni in sistemi sincroni.

2. Conservare una registrazione duratura di questi eventi in modo da poter ripristinare lo stato del sistema in caso di errore del sistema. Se il gestore del gateway di pagamento mantiene questi eventi nella memoria volatile e si blocca, allora sei fregato.

3. Ogni transazione complessa è essenzialmente una serie di trasformazioni di stato basate sull'invio e la ricezione di messaggi (eventi) all'interno del sistema. Sembra che tu stia modellando informalmente questo usando il tuo "record di transazioni in sospeso", ma ti suggerirei di andare oltre: per ogni transazione che devi gestire, crea una macchina a stati formale che la descriva e mantenga una registrazione duratura del suo stato attuale . Scoprirai che queste macchine a stati sono facili da capire, da testare e offrono la necessaria visibilità in questi processi sia per te che per i tuoi utenti.

Più il tuo sistema è asincrono, più formale ed esplicito devi essere quando gestisci queste complesse trasformazioni di stato con eventi. Timeout, registrazione degli eventi durevoli e macchine a stati sono le migliori pratiche qui. Questo è il motivo per cui Erlang OTP basa gran parte del comportamento delle sue applicazioni sul modello di macchina a stati, per esempio.

Per riferimento, non ho trovato niente di meglio di Introduzione alla programmazione distribuita affidabile e sicura . Ti fornirà una solida base algoritmica per comprendere sia i sistemi sincroni che quelli asincroni dai primi principi.