Práticas recomendadas para lidar com intercomunicação assíncrona?

Concluiu recentemente um projeto para lidar com o processamento de cartão de crédito. Uma das dificuldades que enfrentei foi lidar com o atraso / possível falha nas mensagens de notificação. O exemplo mais complexo foi:

• um sistema externo enviando a solicitação de pagamento
• meu sistema transformando essa solicitação em uma solicitação para o gateway de pagamento
• enviando o usuário para o gateway
• aguardando o usuário executar o pagamento
• o usuário retornando ao meu sistema, mas sendo retido até que o sistema receba uma notificação de sucesso / falha
• Enviando o usuário de volta ao sistema externo, dependendo da falha

Ainda mais difícil foi o fato de que, ao não enviar a notificação, o gateway tenta enviá-la a cada 15 minutos, durante várias horas.

Eu o resolvi usando um registro de banco de dados de transações pendentes e, em seguida, detectando sucesso e falha do retorno, além de um ouvinte de atraso cronometrado para a notificação e manipulação de transações ...

Razoavelmente difícil!

Mas isso deve ter sido resolvido um bilhão de vezes antes, então qual é a melhor prática?

Percebo que meu futuro será escrever a manipulação entre todos esses sistemas e gerenciar os atrasos e possíveis falhas de rede, por isso quero seguir as melhores práticas.

As recomendações de livros / artigos seriam ótimas.

Desde já, obrigado!

Ao criar sistemas distribuídos, a diferença entre um sistema 'síncrono' e um sistema 'assíncrono' é o seguinte: Um sistema síncrono possui limites superiores conhecidos nos tempos de entrega da mensagem e da computação. Então: você tem um sistema assíncrono em que determinados eventos não possuem esses limites superiores conhecidos. Como você lida com isso?

1. Se esses processos assíncronos tiverem limites superiores probabilísticos , você poderá usar tempos limite para fazer com que seu sistema atue como um sistema parcialmente síncrono . Se o tempo de resposta do 98º percentil do gateway de pagamento for de 5 segundos, um tempo limite de 5 segundos fará com que 98% de suas solicitações sejam bem-sucedidas e os outros 2% falharão. Isso significa que agora você tem um limite superior conhecido de quanto tempo esse processo levará para ter sucesso ou falhar. Essa detecção probabilística de falhas é uma ferramenta crítica para transformar sistemas assíncronos em sistemas síncronos.

2. Mantenha um registro durável desses eventos para recuperar o estado do sistema em caso de falha do sistema. Se o manipulador do gateway de pagamento mantiver esses eventos em memória volátil e travar, você estará ferrado.

3. Cada transação complexa é essencialmente uma série de transformações de estado com base no envio e recebimento de mensagens (eventos) dentro do sistema. Parece que você está modelando informalmente isso usando seu "registro de transações pendentes", mas eu sugiro que você vá além: para cada transação que você precisa gerenciar, crie uma máquina formal de estado que a descreva e mantenha um registro durável de seu estado atual . Você descobrirá que essas máquinas de estado são fáceis de entender, fáceis de testar e oferecem a visibilidade necessária para esses processos, tanto para você quanto para seus usuários.

Quanto mais assíncrono for o seu sistema, mais formal e explícito você precisará ser ao gerenciar essas complexas transformações de eventos. Tempos limite, registro de eventos durável e máquinas de estado são as melhores práticas aqui. É por isso que o Erlang OTP baseia muito do seu comportamento de aplicativo no modelo de máquina de estado, por exemplo.

Para referência, não encontrei nada melhor que Introdução à Programação Distribuída Confiável e Segura . Ele fornecerá uma forte base algorítmica para entender os sistemas síncronos e assíncronos desde os primeiros princípios.