Meilleure pratique pour gérer l'intercommunication asynchrone?

Récemment terminé un projet de gestion du traitement des cartes de crédit. L'une des difficultés que j'ai rencontrées a été de gérer le retard / l'échec possible des messages de notification. L'exemple le plus complexe était:

• un système externe envoyant la demande de paiement
• mon système transformant cette demande en une demande à la passerelle de paiement
• envoyer l'utilisateur à la passerelle
• attendre que l'utilisateur effectue le paiement
• l'utilisateur retourne à mon système mais reste en attente jusqu'à ce que le système reçoive une notification de réussite / d'échec
• Renvoyer l'utilisateur au système externe en cas d'échec

Plus difficile encore était le fait qu'en cas de non-envoi de la notification, la passerelle tente d'envoyer la notification toutes les 15 minutes pendant un certain nombre d'heures.

Je l'ai résolu en utilisant un enregistrement de base de données des transactions en attente, puis en détectant le succès et l'échec du retour plus un écouteur temporisé pour la notification et la gestion des transactions ...

Assez difficile!

Mais cela a dû être résolu un gazillion de fois auparavant, alors quelle est la meilleure pratique?

Je peux voir que mon avenir va être d'écrire la gestion entre tous ces systèmes et de gérer les délais et les pannes de réseau possibles, donc je veux suivre les meilleures pratiques.

Des recommandations de livres / articles seraient formidables.

Merci d'avance!

Lors de la construction de systèmes distribués, la différence entre un système «synchrone» et un système «asynchrone» est la suivante: un système synchrone a des limites supérieures connues pour le calcul et les délais de livraison des messages. Donc: vous avez un système asynchrone où certains événements n'ont pas ces limites supérieures connues. Comment gérez-vous cela?

1. Si ces processus asynchrones ont des limites supérieures probabilistes, vous pouvez utiliser des délais d' attente pour que votre système se comporte comme un système partiellement synchrone . Si le temps de réponse du 98e centile de la passerelle de paiement est de 5 secondes, un délai d'expiration de 5 secondes fera en sorte que 98% de vos demandes réussiront et les 2% restants échoueront. Cela signifie que vous avez maintenant une limite supérieure connue sur le temps que ce processus prendra pour réussir ou échouer. Cette détection probabiliste des pannes est un outil essentiel pour transformer des systèmes asynchrones en systèmes synchrones.

2. Conservez un enregistrement durable de ces événements afin de pouvoir récupérer l'état de votre système en cas de défaillance du système. Si votre gestionnaire de passerelle de paiement conserve ces événements dans la mémoire volatile et qu'il se bloque, vous êtes foutu.

3. Chaque transaction complexe est essentiellement une série de transformations d'état basées sur l'envoi et la réception de messages (événements) au sein du système. Il semble que vous modélisiez cela de manière informelle à l'aide de votre "enregistrement des transactions en attente", mais je vous suggère d'aller plus loin: pour chaque transaction que vous devez gérer, créez une machine d'état formelle qui la décrit et conservez un enregistrement durable de son état actuel . Vous constaterez que ces machines d'état sont faciles à comprendre, faciles à tester et donnent une visibilité bien nécessaire sur ces processus, pour vous et vos utilisateurs.

Plus votre système est asynchrone, plus vous devez être formel et explicite lorsque vous gérez ces transformations d'état complexes. Les délais d'expiration, la journalisation des événements durable et les machines d'état sont la meilleure pratique ici. C'est pourquoi Erlang OTP fonde une grande partie de son comportement d'application sur le modèle de machine d'état, par exemple.

Pour référence, je n'ai rien trouvé de mieux que Introduction à la programmation distribuée fiable et sécurisée . Il vous donnera une base algorithmique solide pour comprendre les systèmes synchrones et asynchrones à partir des premiers principes.