персистентные структуры - это ets, словарь процесса и environment обычно

Слушайте, даже не смешно

their operations do not (visibly) update the structure in-place, but instead always yield a new updated structure

ну так в Э явно возвращается другая структура. Персистентность - лишь один из вариантов иммутабельности

или наоборот...

обычно понятие персистентности рассматривается шире (например https://habr.com/ru/company/mailru/blog/316634/ - там в комментах много про это) и больше употребляется при сохранении данных на довольно длительное время. иммутабельность же - именно то, о чем спрашивали

эрланговыми либами не пользовался, но по опыту эликсира могу сказать, что лучше собственного велосипеда не найти библиотеку, ибо если брать готовую, то быстро начинаешь упираться в ограничения и особенности реализации, изучаешь все исходники, думаешь "ну и говно странные архитектурные решения" и переписываешь все сам с нуля. Уже на двух проектах такое видел: впиливание библиотеки было зря потраченным временем.

так как ивенты и специфика везде свои, то чтобы сделать универсальное решение приходится идти на много компромиссов. В результате со сторонней либой кода приходится писать в несколько раз больше, чем при реализации паттерна своими силами сразу. А потом оказывается, что шаг влево-шаг вправо, и надо либу переписывать. А еще ее хрен отладишь так как сделана она, например, через подписку на прослушивание ивентов, летящих из БД... и ловить их такое себе развлечение.

Сильно, все таки, зависит от качества кадров
Когда нет скиллов/возможности/желания у персонала запилить свой велосипед, то КМК стоит хорошо проанализировать существующие реализации: плюсы, минусы, компромисы. И подумать, может, получится использовать.
Даже если не подойдёт, всегда пригодиться при написании своей версии: изучены хорошее идеи, поняты ошибки

Если свой велосипед можно написать за неделю или даже две, то надо писать. Если больше то смотреть что есть готового

Собственно говоря, о какой реализации там речь-то вообще идёт?
Если требования банальные, то нужно уметь всего три-четыре вещи
1) Класть эвенты
2) Реплей
3) Снапшот
(Это из требований к хранилищу)

Если же брать взаимодействие сервисов, то оно практически полностью определяется бизнес требованиями и архитектурой взаимодействия

А что это такое?

Архтектурный подход, в котором все команды изменяющие состояние приложения (и не только) проходят через некий Data Layer , который называется Event Store и он хранит все эвенты.
При этом, обязательно чтобы эвенты должны сначала быть записаны в Event Store, а только потом они должны быть обработаны. Если в другом порядке, то это уже Command Sourcing
Этот подход обычно используется если в системе нужно следить за историей её изменений или, например, нужно выявлять некоторые паттерны в поведении пользователей. Повышать уровень безопасности и так далее

Есть маленькая и краткая статья на microservices.io
И я ещё на youtube видел выступление с докладчиком в футболке LFE

gen_event + separate append-only storage для хранения ивентов

Те это паттерн, когда есть полностью перевоспроизводимый лог событий?

Лог команд точнее

CQRS оттуда же

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

Ага, ясно. У нас по такому паттерну выстроен архив

Потом, этих логов может быть несколько...

Это здорово помогло убрать рейсы и рассинхроны из трехслойного уровня индексов