Versão longa:

Eu sou novo em erlang, e considerando usá-lo para uma arquitetura escalável. Encontrei muitos defensores da plataforma divulgando sua confiabilidade e tolerância a falhas.

No entanto, estou lutando para entender exatamente como a tolerância a falhas é alcançada neste sistema em que as mensagens são enfileiradas na memória transitória. Entendo que uma hierarquia de supervisor pode ser organizada para reaparecer processos falecidos, mas não consegui encontrar muita discussão sobre as implicações de reaparecer em trabalhos em andamento. O que acontece com as mensagens em andamento e os artefatos do trabalho parcialmente concluído que foram perdidos em um nó moribundo?

Todos os produtores retransmitirão automaticamente as mensagens que não são aceitas quando os processos do consumidor morrem? Caso contrário, como isso pode ser considerado tolerante a falhas? E, em caso afirmativo, o que impede que uma mensagem processada - mas ainda não reconhecida - seja retransmitida e, portanto, reprocessada inadequadamente?

(Reconheço que essas preocupações não são exclusivas do erlang; preocupações semelhantes surgirão em qualquer sistema de processamento distribuído. Mas os entusiastas do erlang parecem afirmar que a plataforma torna tudo isso "fácil" ..?)

Supondo que as mensagens sejam retransmitidas, posso imaginar facilmente um cenário em que os efeitos posteriores de uma cadeia de mensagens complexa possam ficar muito confusos após uma falha. Sem algum tipo de sistema pesado de transações distribuídas, não entendo como a consistência e a correção podem ser mantidas sem abordar a duplicação em todos os processos. Meu código de aplicativo deve sempre impor restrições para impedir que as transações sejam executadas mais de uma vez?

Versão curta:

Os processos erlang distribuídos estão sujeitos a mensagens duplicadas? Em caso afirmativo, a proteção duplicada (ou seja, a idempotência) é uma responsabilidade do aplicativo ou o erlang / OTP de alguma forma nos ajuda com isso?