выше давали книжку с плоской рыбой. у меня она в бумаге есть. вот там расписано, как писать распределенные приложения так, чтобы они выпадения нод переживали. сам я такое не делал, конечно же ))) не требовалось

по поводу отправил и недоставилось. есть же куча вариантов. к примеру, если nats и ты отправил request то по таймауту тебе должны ответить. если нет - значит еррор. либо natsstream - он, считай, сохранит это дело. теоретически, до момента перезапуска упашего получателя.

сохранение сообщения в mq это такой вариант отсрочить неизбежное ))) лучше всетаки ужасный конец, чем ужас без конца. к тому же, для эрланг ближе и понятнее cast/call. то есть ты отправил и тебе наплевать, дошло или не дошло. либо ты отправил и должен быть ответ в пределах таймаута. если нет, то сразу начинаешь какие-нибудь 500ки отдавать. система девопс мониторинга такие вещи должна автоматически ловить и стучать админам, что что-то пошло не так.

кластер средствами beam это как горячая замена кода. Возможность есть, но без самой крайней необходимости лучше не пользоваться, чтобы не словить кучи лишнего геммороя. В общем случае лучше как можно дольше обходиться без горячей замены кода и держать свои приложения отдельными инстансами. Это, наверное, как с MacOS на Debian Unstable пересесть.Жить и работать можно, но лучше не рисковать)

Скорее так - встроенные механизмы в beam - они очень low-level - это по аналогии, как tcp - возможность коммуникации есть, но поверх тебе нужен какой-то свой протокол(http, grpc и так далее). Т.е. Node.connect есть, но вот чтобы им осмысленно пользоваться тебе нужны распределённые registry, написать failover, заиспользовать стратегию распределения, к примеру, raft(в зависимости от требований к системе разные могут быть)….  И тут встаёт на весы - использовать готовые вещи, типа mq, типа consul, etcd и так далее, где большая половина вопросов уже решена за тебя или использовать нативный erlang distributed и писать поверх него свои абстракции, что явно затратно.

А есть ссылка на доклад?

на хайлоаде пару лет назад был хороший доклад, как правильно готовить кролика. там у докладчика всё хорошо работало, да так, что они в сетевой интерфейс по скорости упёрлись.
так что надо смотреть что там товарищи делают.

под рукой нет. просто как факт запомнил.

в моем сценарии нужен RPC и вероятность падения ноды крайне мала, есть ли смысл городить громоздкий failover ради событий происходящих раз в год и без особых убытков?

Ведь падение ноды бывает разное:
- Нода упала, пользователи не могут войти в личный кабинет.
- Ща, чай допью и починю.

или

- А-а-а-а-а! Нода упала!!! Секунда лежания 1к баксов!!! А-а-а-а-а!!!

Ну, тогда если никаких особых требований ни по скорости, ни по failover-у нет, то можно erlang distributed брать без проблем 🙂

Вы по-моему пытаетесь сравнивать мягкое и длинное. MQ для совсем других задач нужен. Разговоры о том, что ERL кластеризация не работает - это очень странные разговоры. Видимо Discord у этих людей не существует и не работает. Фраза DevOps сказали, что кластеризация сложнее, чем RMQ - видимо DevOps ребята ставят RMQ из коробки и не работают с вещами вроде DLE и прочими, там тот еще ад. Надо применять тот инструмент, который решает проблему, а не тащить везде Redis/RMQ/Kafka если можно решить вопрос DETS/Mnesia + ERL Cluster.

Коллеге, который хотел использовать кластер - используйте и никого не слушайте. Лучше вегда самому пройтись по граблям и понять под какие ситуации хорошо, под какие плохо (как мне кажется для вашего варианта кластер - идеальный).

Коллеге, который топит за RMQ(ну и другие MQ) и говорит о том, что Distributed без MQ вообще не существует - товарищи из телекома звонко ржут над этим заявлением. Ну и куча товарищей из компашек, которые юзают gRPC, QUIC тоже веселятся. MQ хорошо решает определенные задачи, но его мониторинг становится достаточно нетривиальной задачей, а в случае с RMQ кривые руки разработки могут вам и кластер положить, так что с охапкой плюсов вы получаете вагон и маленькую тележку минусов. Distributed без MQ прекрасно себе существует, даже вне пределов Erlang/Elixir. Посмотрите на любые БД, которые умеют в Distributed.

еще популярная тема говорить, что мнезия - говно

С mnesia-ей - работает, пока у тебя кластер не рассыпиться один раз. Прежде, чем брать мнезию в распределенной среде, нужно хорошо разобраться с тем, что делаешь и что будешь делать в случае…. С базами данных шутить не стоит.

вот есть докладик про то, как в aviasales в ней хранят 14_000_000_000 записей

https://youtu.be/x0BlsD-fFqU?t=8032

через час удалю )))

не помню только уже, в кластере оно у них или нет (вроде нет). проблемы были только один раз, когда диск кончился

ага, был на этом митапе, им пофиг - консистентность не нужна, грохнулась база, перезалили 14_000_000_000 записей из основной БД