Versión larga:

Soy nuevo en erlang, y estoy considerando usarlo para una arquitectura escalable. He encontrado muchos defensores de la plataforma promocionando su confiabilidad y tolerancia a fallas.

Sin embargo, me cuesta entender exactamente cómo se logra la tolerancia a fallas en este sistema donde los mensajes se ponen en cola en la memoria transitoria. Entiendo que se puede organizar una jerarquía de supervisores para reaparecer procesos fallecidos, pero no he podido encontrar mucha discusión sobre las implicaciones de reaparecer en trabajos en progreso. ¿Qué sucede con los mensajes en vuelo y los artefactos del trabajo parcialmente completado que se perdieron en un nodo moribundo?

¿Todos los productores retransmitirán automáticamente los mensajes que no se verifican cuando los procesos de consumo mueren? Si no, ¿cómo se puede considerar tolerante a fallas? Y si es así, ¿qué impide que un mensaje que se procesó, pero no se reconozca del todo, se retransmita y, por lo tanto, se reprocese de manera inapropiada?

(Reconozco que estas preocupaciones no son exclusivas de erlang; surgirán preocupaciones similares en cualquier sistema de procesamiento distribuido. Pero los entusiastas de erlang parecen afirmar que la plataforma hace que todo sea "fácil" ...)

Suponiendo que los mensajes se retransmiten, puedo imaginar fácilmente un escenario en el que los efectos posteriores de una cadena de mensajes compleja podrían quedar muy confusos después de una falla. Sin algún tipo de sistema de transacciones distribuidas pesadas, no entiendo cómo se puede mantener la coherencia y la corrección sin abordar la duplicación en cada proceso. ¿El código de mi aplicación siempre debe imponer restricciones para evitar que las transacciones se ejecuten más de una vez?

Version corta:

¿Los procesos de erlang distribuidos están sujetos a mensajes duplicados? Si es así, ¿la protección contra duplicados (es decir, la idempotencia) es una responsabilidad de la aplicación, o erlang / OTP de alguna manera nos ayuda con esto?